Caching Part 8: System Design Interviews — Patterns, Trade-offs, and Model Answers

System design interviews aren't about memorizing solutions. They're about showing you can reason through trade-offs. Caching is one of the most reliable tools in your interview toolbox — but only if you can articulate why you're using it, not just that you're using it.

Where Cache Fits in Your System Diagram

When you draw a system, caching belongs at every bottleneck:

Green boxes = cache layers. In an interview, you don't need all of them. Pick 1-2 and justify:

"I'll add Redis as a distributed cache because the product catalog is read-heavy"
"A CDN makes sense here because we're serving static images globally"

Back-of-Envelope Estimation

Interviewers want to see you can estimate cache size and hit ratio from requirements.

Example: "Cache a product catalog with 10M products"

Input	Value	Reasoning
Total products	10M	Given
Avg product object	2 KB	Name, price, description, image URL
Total raw size	20 GB	10M × 2 KB
Active products (80/20 rule)	2M	20% of products get 80% of traffic
Cache size needed	~4 GB	2M × 2 KB
With overhead (1.3x)	~6 GB	Redis key overhead + safety buffer

// Quick estimation helper
fun estimateCacheSize(
    totalItems: Long,
    avgSizeKB: Int,
    activeRatio: Double = 0.2,
    overheadFactor: Double = 1.3
): String {
    val activeItems = (totalItems * activeRatio).toLong()
    val totalBytes = activeItems * avgSizeKB * 1024
    val withOverhead = (totalBytes * overheadFactor).toLong()

    return when {
        withOverhead < 1024 * 1024 -> "${withOverhead / 1024} KB"
        withOverhead < 1024 * 1024 * 1024 -> "${withOverhead / (1024 * 1024)} MB"
        else -> "${withOverhead / (1024 * 1024 * 1024)} GB"
    }
}

estimateCacheSize(10_000_000, 2)  // ~5.2 GB

The Interview Pattern: Present → Justify → Trade-off

When caching comes up, follow this 3-step pattern:

1. Present: "I'll add a Redis cache layer here."

2. Justify: "The product catalog is read-heavy — 100 reads per write — and the data doesn't change often. A cache will reduce database load significantly."

3. Trade-off: "The trade-off is eventual consistency. If a product price changes, the cache will be stale for up to the TTL. For a product catalog, that's acceptable. If this were inventory, I'd use write-through instead."

Model Answer: "Design Twitter's Timeline"

Problem: Users need to see a feed of tweets from people they follow. 300M users, 500M tweets/day.

Caching decisions:

What to say:

Cache the timeline, not individual tweets. Each user's feed is a sorted set of tweet IDs in Redis.
Two approaches:
- Fan-out on write: When a user posts, push tweet ID to all followers' feed caches. Works for users with few followers.
- Fan-out on read: When a user opens their feed, fetch from DB and cache. Works for celebrities with millions of followers.
Hybrid approach (best answer): Fan-out on write for regular users. Fan-out on read for celebrity accounts (>10K followers).
Invalidation: Tweets are immutable once posted (no updates). New tweets are appended, not modified. This makes caching much easier.
Estimation: 300M users × avg 300 items in feed × 100 bytes per item ≈ 9 TB of feed data. Only cache active users (~30M) → ~900 GB. Needs Redis Cluster.

Green flags interviewers look for: Mentioning the hybrid fan-out approach, estimating cache size, acknowledging that tweets are immutable (simplifying invalidation), and choosing the right data structure (sorted set for chronological ordering).

Model Answer: "Design a URL Shortener"

Problem: Shorten URLs, redirect short URLs to originals. 100M new URLs/day, 10B redirects/day.

Caching decisions:

Cache the redirect mapping. Read-to-write ratio is 100:1 — textbook caching scenario.
Key: short code, Value: original URL. Simple string lookup in Redis.
Strategy: Cache-aside with TTL of 24 hours. URLs rarely change once created.
Estimation: 10B total mappings × avg 200 bytes ≈ 2 TB total. Only cache hot URLs (recent + popular) ≈ 100M × 200 bytes = 20 GB.
Invalidation: Minimal — URLs are write-once. TTL handles cleanup naturally.

Red Flags: What Kills Your Answer

Red Flag	Why It's Bad	What to Say Instead
"I'll add a cache" with no justification	Shows shallow thinking	"I'll add a cache because the read/write ratio is X:1"
Ignoring invalidation	Pretending stale data doesn't exist	"I'll use [strategy] for invalidation because..."
One cache layer for everything	Over-simplified	"Different data needs different caching strategies"
No estimation	Can't justify cache size	"With X items at Y bytes, we need Z GB"
"Just use Redis"	No trade-off analysis	"Redis gives us [X] but costs us [Y]"

Green Flags: What Makes You Stand Out

Mention the 80/20 rule — "20% of data gets 80% of traffic, so we only cache the hot subset"
Articulate trade-offs — "I'm choosing eventual consistency here because..."
Address failure modes — "If Redis goes down, I'll have a circuit breaker to protect the database"
Estimate with numbers — rough calculations show engineering maturity
Know when NOT to cache — "For inventory counts, I'd skip caching because consistency is critical"

Key Takeaways

Present → Justify → Trade-off is the interview pattern for caching decisions
Estimate cache size from requirements using the 80/20 rule
For timelines: hybrid fan-out (write for normal users, read for celebrities)
For lookups: cache-aside with TTL works for most cases
Never say "add a cache" without saying why and what the trade-off is
Red flags: no justification, no invalidation, no estimation, no failure mode
Green flags: trade-offs, numbers, failure planning, knowing when not to cache

Where Cache Fits in Your System Diagram

When you draw a system, caching belongs at every bottleneck:

Green boxes = cache layers. In an interview, you don't need all of them. Pick 1-2 and justify:

"I'll add Redis as a distributed cache because the product catalog is read-heavy"
"A CDN makes sense here because we're serving static images globally"

Back-of-Envelope Estimation

Interviewers want to see you can estimate cache size and hit ratio from requirements.

Example: "Cache a product catalog with 10M products"

Input	Value	Reasoning
Total products	10M	Given
Avg product object	2 KB	Name, price, description, image URL
Total raw size	20 GB	10M × 2 KB
Active products (80/20 rule)	2M	20% of products get 80% of traffic
Cache size needed	~4 GB	2M × 2 KB
With overhead (1.3x)	~6 GB	Redis key overhead + safety buffer

// Quick estimation helper
fun estimateCacheSize(
    totalItems: Long,
    avgSizeKB: Int,
    activeRatio: Double = 0.2,
    overheadFactor: Double = 1.3
): String {
    val activeItems = (totalItems * activeRatio).toLong()
    val totalBytes = activeItems * avgSizeKB * 1024
    val withOverhead = (totalBytes * overheadFactor).toLong()

    return when {
        withOverhead < 1024 * 1024 -> "${withOverhead / 1024} KB"
        withOverhead < 1024 * 1024 * 1024 -> "${withOverhead / (1024 * 1024)} MB"
        else -> "${withOverhead / (1024 * 1024 * 1024)} GB"
    }
}

estimateCacheSize(10_000_000, 2)  // ~5.2 GB

The Interview Pattern: Present → Justify → Trade-off

When caching comes up, follow this 3-step pattern:

1. Present: "I'll add a Redis cache layer here."

2. Justify: "The product catalog is read-heavy — 100 reads per write — and the data doesn't change often. A cache will reduce database load significantly."

Model Answer: "Design Twitter's Timeline"

Problem: Users need to see a feed of tweets from people they follow. 300M users, 500M tweets/day.

Caching decisions:

What to say:

Cache the timeline, not individual tweets. Each user's feed is a sorted set of tweet IDs in Redis.
Two approaches:
- Fan-out on write: When a user posts, push tweet ID to all followers' feed caches. Works for users with few followers.
- Fan-out on read: When a user opens their feed, fetch from DB and cache. Works for celebrities with millions of followers.
Hybrid approach (best answer): Fan-out on write for regular users. Fan-out on read for celebrity accounts (>10K followers).
Invalidation: Tweets are immutable once posted (no updates). New tweets are appended, not modified. This makes caching much easier.
Estimation: 300M users × avg 300 items in feed × 100 bytes per item ≈ 9 TB of feed data. Only cache active users (~30M) → ~900 GB. Needs Redis Cluster.

Model Answer: "Design a URL Shortener"

Problem: Shorten URLs, redirect short URLs to originals. 100M new URLs/day, 10B redirects/day.

Caching decisions:

Cache the redirect mapping. Read-to-write ratio is 100:1 — textbook caching scenario.
Key: short code, Value: original URL. Simple string lookup in Redis.
Strategy: Cache-aside with TTL of 24 hours. URLs rarely change once created.
Estimation: 10B total mappings × avg 200 bytes ≈ 2 TB total. Only cache hot URLs (recent + popular) ≈ 100M × 200 bytes = 20 GB.
Invalidation: Minimal — URLs are write-once. TTL handles cleanup naturally.

Red Flags: What Kills Your Answer

Red Flag	Why It's Bad	What to Say Instead
"I'll add a cache" with no justification	Shows shallow thinking	"I'll add a cache because the read/write ratio is X:1"
Ignoring invalidation	Pretending stale data doesn't exist	"I'll use [strategy] for invalidation because..."
One cache layer for everything	Over-simplified	"Different data needs different caching strategies"
No estimation	Can't justify cache size	"With X items at Y bytes, we need Z GB"
"Just use Redis"	No trade-off analysis	"Redis gives us [X] but costs us [Y]"

Green Flags: What Makes You Stand Out

Mention the 80/20 rule — "20% of data gets 80% of traffic, so we only cache the hot subset"
Articulate trade-offs — "I'm choosing eventual consistency here because..."
Address failure modes — "If Redis goes down, I'll have a circuit breaker to protect the database"
Estimate with numbers — rough calculations show engineering maturity
Know when NOT to cache — "For inventory counts, I'd skip caching because consistency is critical"

Key Takeaways

Present → Justify → Trade-off is the interview pattern for caching decisions
Estimate cache size from requirements using the 80/20 rule
For timelines: hybrid fan-out (write for normal users, read for celebrities)
For lookups: cache-aside with TTL works for most cases
Never say "add a cache" without saying why and what the trade-off is
Red flags: no justification, no invalidation, no estimation, no failure mode
Green flags: trade-offs, numbers, failure planning, knowing when not to cache

Caching Part 8: System Design Interviews — Patterns, Trade-offs, and Model Answers

Caching Deep Dive(9-part series)

Where Cache Fits in Your System Diagram

Back-of-Envelope Estimation

Example: "Cache a product catalog with 10M products"

The Interview Pattern: Present → Justify → Trade-off

Model Answer: "Design Twitter's Timeline"

Model Answer: "Design a URL Shortener"

Red Flags: What Kills Your Answer

Green Flags: What Makes You Stand Out

Key Takeaways

Tags

Related Posts

Caching Part 6: When It Goes Wrong — Thundering Herds, Hot Keys, and Nightmares

Caching Part 4: Eviction Policies — LRU, LFU, and Making Room

Caching Part 1: Fundamentals — Why, When, and When Not to Cache

Caching Part 8: System Design Interviews — Patterns, Trade-offs, and Model Answers

Caching Deep Dive(9-part series)

Where Cache Fits in Your System Diagram

Back-of-Envelope Estimation

Example: "Cache a product catalog with 10M products"

The Interview Pattern: Present → Justify → Trade-off

Model Answer: "Design Twitter's Timeline"

Model Answer: "Design a URL Shortener"

Red Flags: What Kills Your Answer

Green Flags: What Makes You Stand Out

Key Takeaways

Tags

Related Posts

Caching Part 6: When It Goes Wrong — Thundering Herds, Hot Keys, and Nightmares

Caching Part 4: Eviction Policies — LRU, LFU, and Making Room

Caching Part 1: Fundamentals — Why, When, and When Not to Cache