The FYF is not a follow-graph feed — it’s a recommendation feed. The candidate pool is “every video ever uploaded” filtered by ML, not “videos from accounts you follow.” Same fan-out and ranking architecture as Twitter Timeline, but the candidate generation layer is completely different.

Step 1 — Clarify

- Follow-graph feed or pure recommendation? (FYF = recommendation — no follow required)

- Short video only (≤60s) or mixed? This drives storage and encoding decisions - Real-time engagement signals (likes, shares, completion rate) must feed back into ranking within minutes — how fresh?

- DAU? (TikTok: ~1B DAU globally)

- SLO: next video must load in < 500ms — the “infinite scroll” UX depends on it

Step 2 — Estimate

- 1B DAU × 40 videos watched/day = 40B video plays/day = ~463K plays/sec - Each user needs a pre-fetched queue of 10–20 recommended videos to enable instant scroll

- Candidate generation per user: rank top 500 from a pool of billions → return top 20 - Engagement events (play, like, share, skip): ~5 events per video = 200B events/day = 2.3M events/sec feeding the ranking model

Get Access to GitHub Repo

Step 3 — API Design

The prefetch_next_10 in the response is the key design signal — the client pre-fetches the next 10 videos while the user watches the current one, achieving the illusion of instant load.

Step 4 — Data Model

- videos table: video_id, creator_id, s3_key, duration_ms, transcript, embedding (vector), tags[], upload_at

- engagement_events (Kafka → time-series store): user_id, video_id, event_type, watch_pct, timestamp

- user_interest_profile: user_id, topic_vectors[], creator_affinity[], updated_at — updated continuously from engagement stream

- video_recommendation_cache (Redis): user_id → [ordered list of 50 pre-ranked video_ids, TTL=10min]

Read more

This phrase ends more system design answers than any other. It sounds thoughtful. It signals nuance. And it is the single most effective way to tell an interviewer you don’t know how to make a decision.

Every technology choice depends on the use case. That’s not an answer — it’s a preamble. The answer is what it depends on, and how you decide.

Here’s the decision framework for choosing between relational and non-relational storage that works in an interview setting.

Step 1: Write down your two hottest queries

Before naming any storage technology, write down the two or three queries the system will run most frequently. Specifically: what are the inputs, what are the outputs, and what constraints do they have?

“Give me all messages for user X, ordered by time” — this is a range query on a partition key. Wide-column store handles this well.

“Give me all orders for account X with status=pending, joined to the product table” — this has a join. Relational database handles this better.

“Give me the 10 nearest restaurants within 5km of this coordinate” — this is a spatial query. PostGIS or a geohash index.

The storage decision follows from the query. The query never follows from the storage decision.

Subscribe for Payments Walkthrough

Step 2: Apply the decision rules

Use a relational database when:

• Your data is structured and schema is stable

• You need ACID transactions across multiple rows or tables

• Your queries involve joins, aggregations, or complex filtering

• Your write volume is under roughly 5–10K writes per second per node

• Your total data per table is under roughly 100M rows before sharding gets painful

Use a wide-column store (Cassandra, HBase) when:

• You need high write throughput (100K+ writes per second)

• Your queries are predictable and partition-key-based — no joins, no ad-hoc filtering

• Your data is naturally time-ordered (events, messages, metrics)

• You need built-in TTL on rows (messages that expire, session data)

Use a key-value store (Redis, DynamoDB) when:

• Your reads are pure point lookups by a single key

• You need sub-millisecond latency

• You’re storing simple values or small objects

• You need atomic counters or sorted sets

Use object storage (S3) when:

• You’re storing large binary objects (files, images, video, backups)

• You need very high read throughput via CDN

• Latency of 50–200ms per request is acceptable

Step 3: Name the anti-pattern you’re avoiding

The most powerful version of a storage decision isn’t “I’d use Cassandra.” It’s “I’d use Cassandra instead of Postgres here because the write volume — 50,000 events per second — will exceed what a single Postgres instance can handle, and the queries are all partition-key-based so I don’t need the join capability I’d be giving up.”

The comparison forces you to show you considered the alternative. The reason forces you to show you understand the trade-off.

The one rule that overrides everything

If you need a multi-row ACID transaction — an operation where either all rows change or none do — you need a relational database or a relational-compatible distributed database (CockroachDB, Spanner). No amount of Cassandra tuning gives you true ACID across multiple partition keys.

Payment systems almost always need ACID. Account balances must be updated atomically. Inventory reservation must be atomic. Order creation and payment capture must be atomic.

“I’d use Cassandra for the payment ledger” is a common answer that fails almost every payment system design question. The interviewer will ask “what happens if the debit succeeds but the credit fails?” and there is no good answer with Cassandra.

Know what you’re trading away before you trade it.

CTA: The Stripe Payments walkthrough goes deep on exactly this decision — why the ledger needs ACID, how double-entry accounting makes the atomicity requirement explicit, and what happens at the infrastructure level when you enforce it. Paid post #2.

Interested in mastering this topic?

Unlock premium content with deeper explanations and real implementation patterns.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

The inventory reservation problem. A listing is available on specific dates, and two users trying to book the same listing for overlapping dates cannot both succeed. The hard problem: prevent double-booking without making the availability check and reservation a single-threaded bottleneck.

Step 1 — Clarify

- Single room per listing (Airbnb) or multiple rooms (hotel)?

- Search: by location + date range + filters?

- Booking flow: instant book (reserve immediately) or request-to-book (host approves)? - How to handle the “someone else just booked it” race condition?

Step 2 — Data Model

listings: listing_id, host_id, title, location, price_per_night, instant_book (bool) availability: listing_id, date, status (available/blocked/reserved), booking_id (nullable) PRIMARY KEY: (listing_id, date) — one row per listing per night

bookings: booking_id, listing_id, guest_id, check_in, check_out, status

(pending/confirmed/cancelled),

total_price, idempotency_key, created_at

The availability table with one row per listing per night is the key data model decision. Date range availability check = SELECT COUNT(*) FROM availability WHERE listing_id=X AND date BETWEEN check_in AND check_out AND status=’available’. If count = (check_out - check_in) in days, all nights are available.

Get Access to GitHub Repo

Step 3 — Reservation flow (preventing double booking) BEGIN;

-- Check all nights available and lock them

The FOR UPDATE lock on the availability rows means only one transaction can proceed for any given listing+date combination. The second concurrent booking attempt blocks, then fails the count check when it finally runs.

Read more

The most common reason technically strong candidates get a “Hire” instead of “Strong Hire” is not technical depth. It’s running out of time before demonstrating it.

The deep dive section — the hard distributed systems problem at the center of the question — is where L5 separates from L4, and where L6 separates from L5. It’s also the section that gets cut when the interview runs short. You spent 20 minutes on estimation and API design and now you have 10 minutes left for the architecture and zero for the deep dive.

The fix is specific time checkpoints that you self-enforce in the room. Not approximate — specific.

The 50-minute allocation

Here is the allocation that consistently produces complete answers with time for depth:

Total: 45–47 minutes, leaving a 3–5 minute buffer.

Subscribe for Question Walkthrough

The checkpoints to self-enforce

Minute 10: API must be drafted and scope must be locked. If you’re still asking clarifying questions at minute 10, you’ve spent your estimation time and you’ll have to compress the data model.

Minute 22: Schema and key flows should be on the board. At this point you should have: at least two tables sketched with primary keys and indexes, and at least one paragraph of the architecture explained. If you’re still on API design at minute 22, move immediately.

Minute 35: The deep dive must be in progress. Not about to start — actually underway. If you’re at minute 35 with only the high-level architecture sketched and no deep dive started, you have a problem. Stop the high-level walkthrough and pivot to the deep dive now. An incomplete high-level architecture plus a solid deep dive is worth more than a complete architecture with no deep dive.

Minute 48: Trade-offs and failure modes should be underway. If you’re still deep-diving at minute 48, spend the last two minutes naming the top three things that break in your current design and what you’d do about them. Even naming them without a full answer is better than silence.

The discipline required

The hardest part of time management is stopping something that’s going well to move on.

You’re mid-explanation of the data model. It’s going well. You understand this part. The interviewer is nodding. You want to finish the thought.

Move anyway. The next section matters more than this one continued.

The data model section’s job is to demonstrate that you can design appropriate schemas with the right indexes and sharding strategy. Once that’s demonstrated — once you’ve covered the main table, the partition key, and at least one non-obvious design decision — the section is done. More detail doesn’t add signal; it steals time from sections where signal is still available.

What to do when you fall behind

If you realize you’re behind the checkpoints, the correct response is compression, not panic.

For the architecture: “Let me give you the key components and the main flows rather than a complete walkthrough.” Five minutes instead of ten. Names the components, traces one read path and one write path, stops.

For the data model: “The critical table here is the messages table — let me focus on that one rather than all five tables.” Two minutes instead of seven. Names the partition key, names the TTL strategy, stops.

For the API: “Three endpoints — the core create, read, and webhook. Let me sketch those quickly.” Two minutes. Moves on.

Compression is always better than omission. A compressed section signals that you know what you’re doing and are managing time deliberately. An omitted section is a missing signal.

The permission to be incomplete

Most engineers feel they should finish each section before moving to the next. This intuition works in normal engineering work. In a timed interview, it’s wrong.

The interview is scored as a whole, not section by section. A round with complete clarification, estimation, API, data model, architecture, deep dive, and trade-offs — each at 70% coverage — scores better than a round with perfect clarification, estimation, and API at 100% coverage with no deep dive.

The deep dive is the section with the highest score differential. It’s where the round is decided. Everything before it is the setup. Don’t let the setup consume so much time that the payoff never arrives.

CTA: The drill cards have a time-box bar at the bottom of every card — the exact minute allocation for that specific question, weighted toward where the probe lands. All 37 are in the Vault.

Curious how this works in real systems?

The paid lessons cover scalability, optimization, and real-world engineering patterns.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

Same fan-out architecture as Twitter Timeline, but the ranking model is more complex — Instagram ranks not just by recency but by predicted engagement (like, comment, share probability) for each specific user-post pair. The probe is the ranking pipeline and how features are assembled at query time without violating the 500ms SLO.

Architecture delta from Twitter Timeline

Read more

They’re not exotic. They’re not about knowing obscure algorithms. They’re about the difference between an answer that sounds right and an answer that demonstrates you understand what you’re designing.

Gap 1: Numbers that don’t drive anything

Most cohort members can estimate. They get DAU, they calculate requests per second, they calculate storage. The numbers are usually in the right order of magnitude.

Then the next section of their answer proceeds as if the numbers never existed.

“We’ll have approximately 50,000 writes per second” followed by “I’d store user data in a Postgres database.” No mention of whether Postgres handles 50,000 writes per second. No acknowledgment that this number might matter for the technology choice.

The numbers should be the reason for the architectural decisions. Not a box checked before the real answer begins.

The fix is simple: after every estimation number, add one sentence starting with “this means.” 50,000 writes per second — this means a single Postgres instance will be the bottleneck; I’ll need to either shard or move to a write-optimized store like Cassandra. Now the number is doing work.

Gap 2: The happy path only

Most cohort submissions design a system that works when everything goes right. The API is called, the database responds, the message is delivered. The walkthrough is coherent.

Then nothing goes wrong. There are no failure modes. There’s no offline user, no database timeout, no cache failure, no duplicate message delivery.

The simplest version of this is in the messaging question: a candidate designs the delivery path for an online user but never addresses what happens when the recipient is offline. The question literally asks about this. The omission is not subtle.

The fix is one explicit section at the end of every design: “three things that break.” Name them, name the conditions, and describe how you detect and handle each. Even if the answer is “we’d accept degraded behavior and alert on it” — that’s a real answer.

Subscribe for Question Walkthrough

Gap 3: Decisions without reasons

“I’d use Kafka for the event stream.”

Why Kafka? This sentence appears in dozens of submissions every cohort. Sometimes Kafka is the right answer. Sometimes a simple SQS queue would be better. Sometimes a database table with FOR UPDATE SKIP LOCKED is better. The choice depends entirely on the requirements.

When you state a technology choice without a reason, you’re signaling that you know the word, not the trade-off. The interviewer probes exactly here. “Why Kafka over something simpler?” is one of the most common follow-up questions in design interviews.

The fix is to never name a technology without one of these two phrases following it: “because” or “instead of.”

“I’d use Kafka because the producers and consumers have different throughput — decoupling them lets each scale independently.” Now the choice has a reason.

“I’d use Redis instead of Memcached because we need persistence and sorted sets for the leaderboard.” Now the choice has a comparison.

Why these gaps matter more than knowledge gaps

The three things above — numbers with consequences, failure modes, and reasoned decisions — are what experienced engineers do automatically when they design systems. Not because they’re trying to impress anyone. Because they’ve been on-call for systems that failed when the failure mode wasn’t anticipated, and they’ve had to defend technology choices to skeptical colleagues.

The interview is asking: does this person think like someone who has built and operated real systems?

The three gaps signal no, even when the technical knowledge is there.

If your answers have all three gaps, the fix is not more studying. It’s one mock interview where you discipline yourself to add “this means,” “three things that break,” and “instead of” to every section of your answer.

CTA: The cohort curriculum is built around closing exactly these three gaps — each module targets one of them directly.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

Curious how this works in real systems?

The paid lessons cover scalability, optimization, and real-world engineering patterns.

Slack is WhatsApp + channels + threads + search.

The messaging core is identical to WhatsApp (WebSocket, Cassandra, delivery semantics). The probes unique to Slack: channel message fan-out (a channel with 10,000 members means one message = 10,000 deliveries), message threading (replies live in a separate namespace from channel messages), and full-text search over message history.

Step 1 — Clarify

- Direct messages only, or channels + DMs + threads? (Scope to channels + DMs) - Search over message history? (Yes — search is a major Slack differentiator) - Max members per channel? (Slack allows ~10K for standard, unlimited for Enterprise Grid)

- File sharing? (Yes — same object storage pattern as WhatsApp media) - SLO: message delivery < 200ms p99 within same workspace

Step 2 — Estimate

- 20M DAU × 200 messages/day = 4B messages/day = ~46K messages/sec - Average channel size: 50 members → fan-out 50 deliveries per message - Large channels (10K members): 1 message = 10K WebSocket pushes - Message retention: Slack keeps all history (unlimited on paid plans) → ~500 bytes/msg × 4B msgs/day × 365 days = ~730 TB/year

Get Access to GitHub Repo

Step 3 — API Design

WebSocket: wss://slack.com/connect (per workspace per device)

ts (timestamp) is Slack’s actual message ID — a Unix timestamp with microsecond precision, unique per channel.

Step 4 — Data Model

- messages (Cassandra): PARTITION BY channel_id, CLUSTER BY ts DESC — identical pattern to WhatsApp but scoped to channel

- threads: thread_ts (FK to parent message ts), reply messages in same table with thread_ts as additional cluster key

- channel_members: channel_id, user_id, joined_at — indexed both ways (channel→members for fan-out, user→channels for sidebar)

- search_index (Elasticsearch): message ts, channel_id, text, user_id, timestamp — updated async via Kafka consumer

- unread_counts (Redis): user_id:channel_id → {unread_count, last_read_ts} — updated on every message and read event

Read more

The system design interview round has a failure rate that surprises most engineers when they first encounter it. Strong engineers — people who are genuinely good at their jobs, who have built real systems, who know distributed systems concepts — fail this round at a rate that doesn’t correlate with their actual technical competence.

After reading enough post-mortems, the failure pattern is consistent. It’s almost never the technical content.

Failure mode 1: designing instead of scoping

The question is “design Twitter.” The candidate starts designing Twitter. The entire Twitter.

Fifty minutes is not enough time to design a system with the surface area of Twitter. Everyone who attempts to design all of it produces a shallow sketch of everything. The interviewer wanted a deep design of one or two components. The candidate gave a shallow design of twelve.

The fix is the first five minutes of the interview. Use them to scope explicitly: “There are several interesting subsystems here. For this interview, I’m going to focus on the timeline and the fan-out architecture. I’ll acknowledge notifications, search, and ads exist but won’t design them — does that work for you?”

Most interviewers say yes. If they don’t, they redirect you to what they actually want to probe. Either way you’ve avoided spending 45 minutes designing the wrong thing.

Failure mode 2: communicating at the wrong level

“I’d use a database for user data and a cache for performance.”

This sentence tells an interviewer almost nothing. Which database? Which cache? What’s being cached? Why? What’s the eviction strategy? What happens on cache miss?

The problem isn’t that the candidate doesn’t know the answers. They often do. The problem is they’re communicating at the level of “I’ve heard of these technologies” rather than “I understand the trade-offs.”

The fix is the three-sentence pattern: the decision, the reason, and the condition under which you’d change your mind. “I’d use Redis for the timeline cache with LRU eviction and a 24-hour TTL. The hot read pattern is point lookups by user_id, and Redis’s sub-millisecond gets absorb the read load that would otherwise hit Postgres on every feed request. If the working set grows beyond 20% of total DAU being simultaneously active, I’d evaluate a tiered cache.”

That’s the same knowledge communicated at the right level.

Subscribe for Question Walkthrough

Failure mode 3: treating the interviewer as an adversary

The design round is not an oral exam. The interviewer is not trying to catch you out.

Candidates who treat it like an exam defend their choices when challenged, interpret probing questions as criticism, and become less flexible as the round goes on. The interviewer asks “what if the scale was 10× what you assumed?” and the candidate hears “your estimation was wrong” and gets defensive.

The more useful interpretation: the interviewer is helping you get to the interesting part of the question. When they push back, follow their lead. “Good point — at 10× scale, the component that breaks first is the Postgres write path. Let me address that.”

Failure mode 4: running out of time before the deep dive

The deep dive — the hard distributed systems problem at the center of the question — is where the round is decided. It’s where L5 candidates separate from L4, and where L6 candidates separate from L5.

It’s also the section that gets cut when time runs out.

The fix is self-enforcing time checkpoints. Minute 10: API must be drafted, scope locked. Minute 20: schema and key flows sketched. Minute 35: deep dive in progress. Minute 48: trade-offs and failure modes underway.

If you’re at minute 25 with no architecture on the board, the correct move is to stop wherever you are, skip to the architecture, and do it roughly. A rough architecture with a deep dive is more valuable than a complete schema with no architecture.

The pattern

All four failure modes are communication problems, not knowledge problems.

If you’ve done the technical prep and you’re still not passing, the problem is almost certainly one of these four. The fix is not more reading. It’s a timed mock interview with someone who will score you specifically on scope management, communication depth, interviewer collaboration, and time allocation.

Knowledge gets you to the room. Communication gets you the offer.

CTA: If you recognise one of these four failure modes in your own prep — reply and tell me which one. I answer every reply and if you describe your specific situation I’ll point you to the right resource.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

This question is asked as a standalone (”design a distributed cache”) and as the deep-dive in almost every other system design question (”you mentioned adding a cache — walk me through how you’d build that”). It tests whether you understand cache eviction, consistent hashing, replication, and what happens when a cache node fails.

The Question

“Design a distributed in-memory cache like Redis. Support GET and SET operations. The cache should be fast, scalable, and handle node failures gracefully.”

Step 1 — Clarify

1. Capacity? Total data size to cache. This determines how many nodes you need. A single Redis instance handles ~10–25 GB of working memory effectively.

2. Eviction policy? LRU (least recently used) is the most common. Also: LFU (least frequently used), FIFO, TTL-based expiry. State which one unless the interviewer specifies.

3. Write policy? Write-through (update cache and DB simultaneously — strong consistency, higher write latency) vs write-around (bypass cache on writes, populate on read) vs write-back/write-behind (write to cache first, async persist to DB — lower latency, risk of data loss).

4. Read policy? Cache-aside (application checks cache first, populates on miss) vs read-through (cache automatically fetches from DB on miss). Cache-aside is the default; read-through requires the cache to know the DB schema.

5. Replication? Single leader + replicas (Redis Sentinel model) or leaderless (Redis Cluster model)?

Step 2 — Estimate

- 10 TB of data to cache across the cluster

- Target: < 1ms p99 for GET/SET

- Each node: 25 GB RAM → 400 nodes for 10 TB

- Throughput: 500K ops/sec per node → 200M ops/sec cluster capacity - Network: 1 Gbps per node, each GET returns avg 1 KB → 1M GETs/sec per node on bandwidth alone

The key insight: at 400 nodes, the routing layer (consistent hashing) must direct each request to the right node in < 0.1ms overhead, leaving < 0.9ms for the actual lookup.

Get Access to GitHub Repo

Step 3 — Core Data Structures

Hash table with LRU eviction:

The cache is essentially a hash map + a doubly-linked list for LRU tracking.

- Hash map: key → (value, pointer to LRU list node) — O(1) GET

- Doubly-linked list: most-recently-used at head, least-recently-used at tail - On GET: move the accessed node to the head of the list — O(1)

- On SET: add to head. If capacity exceeded: remove from tail (evict LRU) — O(1) - On eviction: remove from hash map and list simultaneously — O(1)

This O(1) for both GET and eviction is the data structure insight interviewers test. A naive LRU using a sorted list would be O(N) on every access.

Step 4 — Consistent Hashing (the probe)

With 400 nodes, how do you decide which node stores key K?

Naive modulo hashing: node = hash(key) % N. Simple. But when you add or remove a node (N changes), nearly every key remaps to a different node. A node failure or scale event causes a cache stampede — every miss hits the DB simultaneously.

Consistent hashing:

Place nodes on a circular ring (0 to 2³² - 1). Each node is assigned a position by hashing its identifier. To find the node for key K: hash K, find the nearest node clockwise on the ring.

Read more

This sentence appears in roughly 60% of system design interview answers involving a database. Sometimes it’s correct. Often it isn’t. Almost always it’s stated without the reasoning that determines whether it’s right or wrong.

The reasoning is everything. The partition key isn’t a preference — it’s a consequence of your read pattern.

The rule

Partition on the dimension you query by most frequently.

If the most common query is “give me all messages for user X” — partition by user_id. Every message for user X is on the same shard. One network hop.

If the most common query is “give me all messages in conversation C” — partition by conversation_id. Every message in conversation C is on the same shard.

Partition by sender_id in a messaging system where reads are by recipient? Every delivery requires querying every shard. You’ve distributed your data in a way that makes your hot read path maximally expensive.

How to get it right

Before naming a partition key, write down the two or three most frequent queries the system needs to serve. Then choose the partition key that makes those queries hit one shard.

For a payment system: the hot query is “give me all transactions for account X.” Partition by account_id.

For a ride-sharing system: the hot query is “give me all active drivers within 5km of this point.” Geohashing is the partition key — drivers in the same geohash cell land on the same shard.

For a social feed: the hot query is “give me all posts for user X’s followers, sorted by time.” Partition by user_id — each user’s feed is co-located.

Subscribe for Question Walkthrough

The celebrity problem

Even correct partition key choices have a failure mode: hot partitions.

If you partition a social graph by user_id and one of your users is a celebrity with 100 million followers, every follow/unfollow event writes to one shard. Every timeline read for those 100 million followers potentially reads from one shard. That shard is getting 100× the load of any other.

The fix depends on what’s hot. For write-heavy celebrities: scatter their data across multiple shards using a compound key (user_id + bucket_id), then merge at read time. For read-heavy content: replicate it across shards so reads can be served locally.

The L5 answer names the hot partition problem. The L6 answer names the specific fix and the conditions under which you’d apply it.

The mechanical keys worth memorizing

Some partition key decisions are standard enough that deviating from them signals a mistake:

Messages: by recipient_id (the hot read is “messages for user X”)

Notifications: by user_id (same reason)

Ride locations: by geohash (the hot read is proximity query)

Payment transactions: by account_id (the hot read is account history)

Web sessions: by session_id (the hot read is session lookup by ID)

Analytics events: by event_time or by (user_id, date) if per-user queries dominate

When you name a partition key in an interview, the follow-up is almost always: “what’s the failure mode?” The correct answer is almost always: “hot partitions when the distribution is uneven — here’s how I’d detect and address them.”

What “sharding” actually is

One last thing worth naming explicitly: sharding and partitioning are often used interchangeably in interviews, but they mean slightly different things. Partitioning is dividing data logically. Sharding is distributing those partitions across separate physical nodes. When interviewers ask “how would you shard the users table?” they mean both.

The answer format that works: state the partition key, explain why it fits the read pattern, name the hot partition risk, and describe the mitigation. Four sentences. Every sharding answer.

CTA: The distributed cache walkthrough (paid post #10) goes deep on consistent hashing and the hot partition problem specifically — including the virtual nodes fix and the thundering herd mitigation when a shard fails.

Interested in mastering this topic?

Unlock premium content with deeper explanations and real implementation patterns.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

The reason: it has a clear probe (the trie data structure and its distributed form), and it reveals whether candidates

understand read-heavy system optimization, pre-computation, and the latency constraints of real-time user interaction.

The Question

“Design the search autocomplete / typeahead system. As a user types in a search box, the system suggests the top 5–10 completions in real time.”

Variants: “Design Google search suggestions,” “Design Twitter’s search autocomplete,” “Design Amazon’s search bar.”

Step 1 — Clarify

1. What goes in suggestions? Historical search queries (Google-style), titles in a product catalog (Amazon-style), or usernames/topics (Twitter-style)? The data source changes the indexing strategy significantly.

2. How many queries is the system handling? Google processes ~100K searches/sec. For most interviews: 10M DAU × 10 searches/day = 100M searches/day = ~1,200/sec average, 10K/sec peak.

3. How fresh must suggestions be? Do new trending searches need to appear in suggestions within minutes, or is 24-hour staleness acceptable? Real-time freshness is much harder. Start by assuming daily updates — offer to discuss real-time as an extension.

4. Personalized or global? Global suggestions (same results for all users) are vastly simpler. Personalized (based on your history) requires per-user ranking on top of the global index.

5. Latency SLO? Suggestions must appear within 100ms of each keystroke to feel real-time. This is the hardest constraint in the system.

Step 2 — Estimate

- 10K search requests/sec at peak (one autocomplete request per keystroke) - Average query length: 20 characters → 20 requests per search session in the worst case

- Top-K queries to track: top 10 million unique queries globally

- Trie storage: each node is ~16 bytes (character + children pointers + metadata) — a trie of 10M queries averages ~50M nodes × 16 bytes = 800 MB. Fits in memory on a single machine.

- Response size: 5–10 query strings, avg 30 bytes each = 300 bytes per response

The 800 MB insight is critical. The entire suggestion index for most production systems fits in memory. This is what enables sub-millisecond lookups.

Get Access to GitHub Repo

Step 3 — Data Model and Core Data Structure

The trie

A trie (prefix tree) is the natural structure for autocomplete. Each node represents a character. A path from root to a node spells a prefix. Each node stores the top-K completions for that prefix.

The key design choice: Pre-compute and cache the top-K results at every node in the trie. This trades storage for latency — instead of traversing to all leaf nodes on every query, the answer is stored at the prefix node. Query time: O(len(prefix)) — just traverse down the trie.

Without pre-computation: query time is O(all_suffixes) — must find all strings below the current node and rank them.

query_frequency table (offline aggregation source)

query_text, frequency_count, last_updated_at

This is the source of truth for what goes in the trie. Updated daily via a MapReduce / Spark job over the day’s search logs. The job counts query occurrences, normalizes (lowercase, trim), and writes the top-N queries per prefix into the trie build pipeline.

Step 4 — Architecture

Three components with different update cadences.

Query service (read path — latency-critical)

1. Client types a character → sends GET /suggest?q=sea

2. Request hits a load balancer → routes to one of N Trie servers (in-memory trie, sharded by prefix range or consistent hash)

3. Trie server traverses the trie in O(len(query)) time → returns top-5 cached completions 4. Response cached at CDN edge (short TTL — 60 seconds) for common prefixes (typing “the” returns the same results for everyone)

5. Total latency: < 10ms (CDN hit) or < 50ms (trie server hit)

Trie build service (write path — offline, daily)

1. Raw search logs → Kafka → Spark/Flink streaming job

2. Aggregation job computes top-10M queries by frequency for the trailing 7 days

3. Trie builder constructs a new trie from scratch and pre-computes top-K at every node 4. New trie serialized to S3

5. Trie servers download and hot-swap the in-memory trie (blue-green style — new trie loaded in background, traffic cut over atomically)

The hot-swap is the L5+ signal. Naive implementations rebuild the trie in place and serve stale or partially-built data during the rebuild. The correct approach: build the new trie entirely before serving any requests from it.

Trending query ingestion (real-time extension)

For real-time freshness (new trending query appears within minutes):

1. Search events stream to Kafka

2. A windowed aggregation job (5-minute tumbling window) identifies queries surging in frequency

3. Trending queries are injected into the trie via a small patch update (not a full rebuild)

4. Patch propagates to all trie servers via pub-sub

This is the L6 extension — daily batch covers the base case, real-time streaming handles trending. Name both.

Read more

Here’s what those signals look like and what to do with each one.

Signals that you’re on track

“That’s interesting — tell me more about that.”

This is the best signal you can receive. The interviewer is engaged, they want to go deeper on something you said, and they’re inviting you to. Do it immediately. Whatever you were about to say next, pause it. Go deeper on the thing they asked about.

The mistake: treating this as confirmation that everything is fine and continuing your prepared flow. The interviewer told you where the interesting part of the question is. Follow them there.

Consistent nodding during a long explanation means you’re not losing them. Keep the same pace and depth.

A follow-up question that goes one level deeper on something you said — not redirecting to a new topic, but drilling into something you introduced — means the interviewer found your point substantive. This is different from a question that redirects you elsewhere

Signals that you need to change direction

“Let’s skip ahead to...” or “Actually, let’s focus on...”

The interviewer is redirecting you. This is not a signal that you did something wrong. It’s information: you’ve covered the previous section sufficiently, or you’re spending time on something that isn’t the probe they care about, or they have a specific component they want to evaluate and they’re efficiently navigating you there.

The correct response: stop mid-sentence if necessary. Don’t finish the paragraph. Say “Sure” and immediately go to where they’re pointing.

The wrong response: finishing your current point before the redirect. Taking 90 seconds to wrap up before pivoting. Explaining why you were going in the direction you were before changing direction.

None of these explanations are useful to the interviewer. The redirect supersedes everything else. Follow it immediately.

“What are the trade-offs?” immediately after you make a decision means: you stated the decision without justifying it. This is a probe, not a compliment. Answer it: what did you choose, what are you giving up, and what would change your mind.

Subscribe for Question Walkthrough

Signals that you’ve misunderstood the question

“What if this needs to work globally?”

“Let’s say the scale is 100× what you assumed.”

“Actually, multiple users can edit the file simultaneously.”

These are corrections. Not gentle suggestions — the premise you’ve been designing for is wrong and the interviewer is telling you.

The correct response: stop, acknowledge once (”Good point — let me revise”), immediately build forward on the corrected premise.

The wrong response: defending the original premise, explaining why the correction doesn’t change things significantly, or taking two minutes to re-explain your reasoning before accepting the correction.

One acknowledgment, then forward. The interviewer doesn’t need to understand why you made the original assumption. They need to see you incorporate new information and keep moving.

The silence probe

When you finish a section and the interviewer doesn’t immediately respond — they look at you, or look at the whiteboard, or just wait — this is almost always an invitation to go deeper.

The silence is not “that was fine, continue to the next section.” It’s “there’s more here, keep going.”

Most candidates treat silence as a signal to move on. The silence probe is actually the opposite: the interviewer has heard the surface answer and wants to see if you’ll surface the deeper one without being explicitly asked.

If you finish a section and get silence, don’t move to the next section. Go deeper on what you just said. Name a failure mode. Name a condition under which your design breaks. Name what you’d add with more time.

If you’ve genuinely exhausted the depth on that component, say so explicitly: “I think I’ve covered the core design here — should I move on to the data model?” This forces a response rather than leaving both of you in ambiguous silence.

Using the interviewer actively

The best candidate-interviewer dynamics aren’t interviews — they’re conversations. Candidates who treat the interviewer as a collaborator rather than an examiner consistently do better.

“I’m torn between two approaches here — let me think through both with you” is collaborative.

“I’m not sure which way this scales better — what factors would you weight more heavily?” is collaborative. It’s also information-gathering: if the interviewer says “I’d think about the write path specifically,” they’ve just told you where the probe is going.

This doesn’t mean delegating decisions to the interviewer. You still need to make choices and defend them. But using the interviewer as a thinking partner — bringing them into your reasoning process rather than presenting finished conclusions — produces a fundamentally different conversation.

That conversation is easier to score well on, because the interviewer has seen how you think, not just what you concluded.

CTA: The mock interview partners channel in the Discord is the fastest way to practice reading a real interviewer — not just a timer. Paid subscribers only.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

The rate limiter question is compact, deceptively hard, and asked everywhere. It tests whether you understand distributed systems coordination problems — specifically, how to enforce a global limit across a cluster of servers when no single server sees all requests. At L5 the probe is the algorithm choice. At L6 the probe is distributed coordination without a single point of failure.

The Question

“Design a rate limiter. API clients are limited to N requests per second. Requests that exceed the limit return 429 Too Many Requests.”

Common variants: “Design Cloudflare’s rate limiting,” “Add rate limiting to a payment API,” “Design a per-user request quota system.”

Step 1 — Clarify

1. What are we rate limiting on? Per IP, per user/API key, per endpoint, or combinations? Answer: typically per API key at the application level, per IP at the network edge.

2. What granularity? Requests per second, per minute, per hour, per day? Multiple windows simultaneously (100 req/min AND 1,000 req/hour)?

3. Hard limit or soft? Hard: the 101st request this minute is always rejected. Soft: occasional burst allowed. Most production systems use hard limits.

4. Where does the limiter live? Middleware inside the API service, or a standalone sidecar/gateway? Standalone scales independently and is language-agnostic — correct answer for L5+.

5. What’s the SLO? The rate limiter must add < 1ms p99 latency to every request. It is in the hot path.

Step 2 — Estimate

- 50,000 API servers in a large deployment, each handling 10K req/sec - Total: 500M requests/sec — individual counters per API key must be updated atomically at this rate

- Redis cluster: 100K-500K ops/sec per node — need ~1,000-5,000 Redis nodes for 500M req/sec. In practice, shard by API key.

- Counter storage: 1M API keys × 4 bytes per counter × 60 windows = 240 MB — fits in memory

Get Access to GitHub Repo

Step 3 — API (internal interface)

Step 4 — Algorithm choice (the core probe)

Four real algorithms. The senior answer names all four, picks one with justification, and explains what changes at L6.

Fixed window counter

Divide time into fixed 1-minute windows. Count requests per window per API key. Reset at window boundary.

Win: Simple. O(1) time and space. One Redis INCR per request.

Lose: Boundary burst problem. A client can send 100 requests at 12:00:59 and 100 more at 12:01:01 — that’s 200 requests in 2 seconds while the “limit” is 100/minute. The window reset creates a seam they can exploit.

Sliding window log

Store the timestamp of every request in the last 60 seconds. On each request, count entries in the log and reject if > limit.

Win: Perfectly accurate. No boundary burst.

Lose: O(N) storage per API key (N = limit). For 1,000 req/min across 1M API keys, that’s 1 billion stored timestamps — expensive.

Sliding window counter (hybrid) ← correct answer for most interviews

Approximate the sliding window using two fixed-window counters: the current window and the previous window. Estimate the request count for the sliding window as:

rate = prev_count × (1 - elapsed_fraction) + curr_count

Where elapsed_fraction = how far into the current window we are. If we’re 30 seconds into a 60-second window, the weight of the previous window is 0.5.

Win: O(1) space per API key. Accurate within ~0.003% of the true sliding window (published by Cloudflare). No boundary burst exploit.

Lose: Approximate (but the error is tiny). Slightly more complex than fixed window.

This is what Cloudflare uses in production — they published a blog post on it. Saying “Cloudflare published their sliding window counter approach” is an L5+ signal.

Token bucket

Each API key has a bucket of capacity N tokens. Tokens refill at rate R per second. Each request consumes one token. If the bucket is empty, the request is rejected.

Win: Allows controlled bursting — a client can use saved-up tokens in a burst. Better user experience for legitimate burst traffic.

Lose: Two values to track per key (current tokens, last refill timestamp). Slightly harder to implement atomically.

When to use: When the product requirement explicitly allows bursting (e.g., “allow up to 50 requests in any 1-second burst as long as the 1-minute average is under 100/min”). For strict per-second limits, sliding window counter is simpler.

The senior recommendation: Default to sliding window counter (Cloudflare’s approach) for strict per-second/per-minute limits. Token bucket for burst-tolerant limits where the product explicitly needs it.

Read more

Learn System Design with System building, Subscribe Hands On coding course - LogStream

Every few weeks, someone posts in the Discord’s #offers-landed channel. L5 at Google. Senior at Stripe. Staff at DoorDash. L6 at Meta after two prior failed loops.

I read every one. After enough of them, patterns become visible. The engineers who pass consistently are not uniformly technically stronger than the ones who fail. They are systematically different in three specific ways.

They scope, then go deep. Not the other way around.

The most common failure mode I hear in post-mortems from engineers who got “No Hire” is some version of: “I designed a great system but ran out of time before the hard part.”

Every engineer who has passed at L5 or above in the last six months has told me some version of the same thing: they spent the first five minutes explicitly scoping — “I’m going to focus on the timeline and the fan-out architecture, and I’m going to acknowledge but not design the notifications, search, and ads” — and then went deep on the one component they chose.

The engineers who fail design everything shallowly. The engineers who pass design one thing deeply.

This is not a trivial shift. Most engineers feel obligated to cover everything. The pressure to show breadth is real. Resisting it and committing to depth in the first five minutes is a deliberate choice that requires practice.

Subscribe for Question Walkthrough

They say the hard thing out loud before the interviewer asks.

The standard pattern in a design interview is: candidate draws the happy path, interviewer probes the failure case, candidate scrambles to address it.

The pattern in successful candidates is different: candidate draws the happy path, then immediately says “the part of this design I’m most concerned about is the thundering herd when the cache node recovers — let me address that.” The probe never comes because the candidate already went there.

This signals something important: not just that you know the failure mode, but that you think about your own designs critically. That’s the operational maturity signal. It’s very hard to fake, and it’s very clear when it’s present.

They treat the interviewer as a collaborator, not an examiner.

This one is harder to describe but unmistakable when you see it.

Candidates who fail tend to treat the design round as a test — something being administered to them. They present, the interviewer asks, they defend. The dynamic is adversarial even when the interviewer is trying to be helpful.

Candidates who pass tend to use the interviewer. “I’m considering two approaches here — let me think through both with you.” “Does this constraint change which way you’d go?” “I’m not sure which way this scales better — what’s your intuition?”

This works for two reasons. First, it makes the interview feel collaborative, which influences the interviewer’s overall impression. Second, and more importantly, it gets you real information. When you say “I’m torn between these two approaches” and the interviewer says “let’s explore the second one,” they’ve just told you where the interesting part of the question is. That’s not cheating — that’s good communication.

What these three things have in common

None of them are technical. Scoping, self-critique, and collaboration are all communication skills. They’re skills you can practice in a mock interview. You cannot practice them by reading another walkthrough.

The most common mistake I see in prep is the ratio: 90% reading walkthroughs, 10% timed drills with feedback. The engineers who pass consistently tend to invert that ratio in the final 4 weeks before the interview.

The knowledge is necessary. It’s just not sufficient.

If you’ve been reading this newsletter and feel solid on the technical content, the thing to do next is not to read more. It’s to schedule a mock with someone who will score you honestly on scoping, critique, and collaboration — not just on whether you knew consistent hashing.

CTA:

Paid subscribers get one full system design walkthrough

every Tuesday — each mapped to its archetype so you build

pattern recognition, not answer memorization.

This week: Rate Limiter.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

Curious how this works in real systems?

The paid lessons cover scalability, optimization, and real-world engineering patterns.

This is the question that defines the file sync and storage archetype. Eight questions in the question bank are variants — iCloud Photos, distributed file systems, cloud backup services, Git-style version control storage, CDN edge caching. They share a spine: chunked file storage, metadata management, multi-device consistency, and conflict resolution. Internalize this one and you can answer all eight.

The surface question sounds like object storage with a UI. The probe underneath is what separates candidates: what happens when two devices modify the same file simultaneously? That conflict resolution problem — deceptively simple on the surface, genuinely hard in distributed systems — is where every L5+ interview on this question goes.

For L4 / mid-level: upload/download flow and basic chunked storage. For L5 / senior: delta sync (only transfer what changed, not the whole file), deduplication, and conflict detection. For L6 / staff: vector clocks or last-writer-wins with operational transforms for true conflict resolution, the consistency model across devices, and what Dropbox actually does differently from naive S3.

The Question

“Design Google Drive or Dropbox. Users upload files from their devices. Files are accessible from any of their devices and sync automatically when changed.”

Common variants:

- “Design iCloud Drive / Apple Files.”

- “Design a cloud backup service.”

- “Design the file sync layer for a collaborative tool.”

- “Design a distributed file system.”

Step 1 — Clarify Before You Draw

1. Individual file storage or collaborative editing? Dropbox stores files — one writer at a time, sync on save. Google Docs is collaborative editing — multiple simultaneous writers with operational transforms. These are fundamentally different systems. Clarify and scope to Dropbox-style unless told otherwise.

2. What file types and size limits? Documents, images, video — or everything? Max file size matters: Dropbox supports files up to 50 GB. A naive single-upload approach collapses above a few hundred MB.

3. Multi-device sync — how many devices per user? Average user: 3–5 devices. Power user: 10+. Each device must receive all changes to synced folders. This drives the notification and sync architecture.

4. Versioning and deleted file recovery? Most cloud storage products retain file versions (Dropbox keeps 30–180 days of version history). Deleted files go to trash with a retention window. State the assumptions.

5. What scale? Dropbox at its peak: 700 million registered users, 500 million files uploaded per day. Working assumptions: 100M DAU, 1B files stored, average file size 1 MB.

6. What’s the SLO? File upload acknowledges within 5 seconds for files under 10 MB. Sync propagates to other devices within 30 seconds of the change. These two SLOs drive the architecture.

Step 2 — Estimate

- 100M DAU, each uploads/modifies ~5 files/day average → 500M file operations/day → ~5,800 ops/sec

- Average file size 1 MB → 5.8 TB/day of new or modified data ingested - Total files stored: 1B files × 1 MB average = 1 PB

- With deduplication (identical files stored once): real storage closer to 400–600 TB (60% dedup ratio is typical)

- Metadata per file: ~500 bytes (name, path, size, hash, version, owner, timestamps) → 500 bytes × 1B files = 500 GB of metadata — fits comfortably in a sharded relational database

- Change notifications: 500M operations/day / 86,400 seconds × 3 devices per user average = ~17,000 notification fanouts/sec

The deduplication estimate is the senior signal in estimation. Dropbox publicly states that deduplication dramatically reduces storage costs because many users store the same files (PDFs, installers, stock photos). Mentioning deduplication in the estimation shows you’ve thought about the system’s economics, not just its architecture.

Get Access to GitHub Repo

Step 3 — API Design

Chunked upload with presigned URLs. Files go directly from the client to S3 — the API server never handles the binary data. This eliminates the API tier as a bandwidth bottleneck. The upload_id ties the chunks together; the etags from each chunk PUT allow S3 to assemble the final object via S3 multipart upload completion.

The /sync/changes endpoint with cursors. This is the Dropbox API model (they call it list_folder/continue). Instead of polling “what changed since timestamp X,” the client maintains an opaque cursor that encodes its sync state. The server returns everything the client has missed since that cursor position. This handles offline sync correctly: a device that was offline for 2 weeks reconnects, passes its cursor, and gets all 2 weeks of changes in one call.

The /conflict endpoint. Most candidates forget this exists. Conflict resolution is a user-facing operation — the client detects a conflict, shows the user, and the user or the system decides. Having an explicit endpoint for conflict resolution signals you’ve thought about the user-facing side of the distributed systems problem.

Step 4 — Data Model

files table

The content_hash → storage_key mapping is the deduplication mechanism. Before storing a file, the server checks whether content_hash already exists in the storage index. If it does, it reuses the existing S3 object and just creates a new metadata row pointing to it. The same file can be “owned” by millions of users but stored in S3 once.

file_versions table

version_id, file_id (FK), version_number, content_hash, size_bytes,

storage_key, created_by_device_id, created_at, is_current

Every modification creates a new version row. The is_current flag moves to the newest version. Old versions are retained for 30 days (configurable), then the storage_key reference is eligible for deletion if no other version or file points to it.

sync_cursors table

cursor_id, device_id, user_id, last_processed_change_id, updated_at

Each device has a cursor. When the device calls /sync/changes, the server returns all changes after last_processed_change_id for that user, then updates the cursor. The cursor is device-specific, not user-specific — each device tracks its own sync position independently.

change_log table — the sync feed

change_id (SEQUENTIAL), user_id (INDEXED), file_id, change_type

(created/modified/deleted/moved),

version_id, changed_by_device_id, changed_at

This is the append-only event log that drives sync. Every file operation appends a row. When a device calls /sync/changes?cursor=X, the query is simply: SELECT * FROM change_log WHERE user_id=:uid AND change_id > :cursor_change_id ORDER BY change_id LIMIT :limit. Fast, simple, correct.

The change_id is a sequential integer (not UUID). Sequential IDs make the range query above maximally efficient. They can be generated by Postgres sequences on a per-user basis, or by a distributed ID sequence (Snowflake-style, with the user_id encoded in the ID).

Read more

Learn System Design with System building, Subscribe Hands On coding course - LogStream

Thirty days. One onsite loop. Here’s the plan I’d actually follow — not the plan that covers everything, because thirty days cannot cover everything, but the plan that prepares you for the specific interview in front of you.

The principle: targeted depth beats broad coverage

Thirty days of prep that covers six archetypes shallowly will lose to twenty days of prep that covers two archetypes deeply, plus ten days of mock interviews.

The engineers who pass consistently aren’t universally prepared. They’re specifically well-prepared for the questions they’re most likely to face. At most companies, a single loop involves one or two system design questions. If you know your target company’s interview patterns, you know which two archetypes to prioritize.

Research your target company before you start prep. Look at Glassdoor, Blind, and LinkedIn connections who’ve interviewed there recently. Identify the two most commonly asked archetypes. Those are your week 1 and week 2.

Subscribe for Question Walkthrough

Week 1 (Days 1–7): Deep drill, archetype #1

Pick the most likely archetype for your target company. Read two walkthroughs from that archetype fully. Don’t drill yet — read to understand the pattern.

Then do three timed cold drills from that archetype on days 3, 5, and 7:

• Set a 50-minute timer

• Design on paper with no notes, no searching

• When the timer ends, open the walkthrough and compare section by section

• Write down the top 3 specific gaps between your answer and the walkthrough

By day 7, you should produce a structurally correct answer — not perfect, but with the right components in the right places and the key failure modes named.

Week 2 (Days 8–14): Deep drill, archetype #2

Same structure. Different archetype — your second most likely one.

After two weeks, you have deep coverage of the two archetypes most likely to come up. That alone puts you in better position than most candidates who drilled 15 questions shallowly.

Week 3 (Days 15–21): Coverage and breadth

Spend week 3 doing shorter 30-minute drills across 4–5 archetypes you haven’t deeply covered. The goal is exposure, not mastery. Knowing the basic shape of an answer for a question you’re 20% likely to face is much better than having no answer.

The 30-minute format requires discipline: force yourself to reach the architecture step within 15 minutes. Don’t let estimation and API design consume your entire drill — practice moving through the framework efficiently.

Also in week 3: re-read the estimation numbers cheatsheet and the trade-offs cheatsheet. These apply to every question. Refreshing them mid-prep rather than at the very end gives them time to consolidate.

Week 4 (Days 22–28): Two mocks with real feedback

Stop reading. Stop drilling solo. Do two mock interviews with people who will give you specific, scored feedback.

The first mock: peer at your target level. Ask them to score you on the 8 dimensions of the take-home rubric. Ask them specifically whether your scoping, communication, and failure mode coverage were strong.

The second mock: someone above your target level. Their feedback will be harder to hear and more useful. What L6 candidates do that you’re not doing yet — that’s the gap you have four days to close before the interview.

After each mock: identify the single most impactful change. Spend two days on that one thing. One change made well is more valuable than ten changes made half-heartedly.

Days 29–30: Consolidation only

Day 29: one short drill (30 minutes), no new material. Re-read the framework cheatsheet. That’s it.

Day 30 (the day before): re-read the drill card for the archetype most likely to come up at your target company. This takes four minutes. Then stop.

Don’t read a new walkthrough the night before. New information the night before competes with everything you’ve consolidated and doesn’t have time to integrate. Rest is a legitimate and important part of preparation. Use it.

What this plan produces

After thirty days:

• Two archetypes with genuine depth and pattern recognition

• Coverage-level familiarity with four to five additional archetypes

• Two mocks with documented gaps and one specific improvement made to each

• The framework cheatsheet and estimation numbers fresh in working memory

You’ll encounter a question you’re less prepared for. When that happens, apply the framework. The six-step framework works on questions you haven’t drilled — that’s what it’s for. The warmup from four weeks of drilling makes the framework run faster and more automatically under pressure.

The thing most people get wrong

The ratio of reading to drilling in most engineers’ prep is about 80:20. Reading walkthroughs, reading concept explainers, reading other people’s summaries.

The ratio that produces results is closer to 40:60 — 40% reading and learning, 60% timed drills and mocks. The performance gap between knowing something and producing it under pressure in front of someone is real and only closes with practice under pressure.

If you have thirty days and you spend twenty-five of them reading, you’ve done the easy part and skipped the hard part. Do the hard part.

CTA:

Paid subscribers get one full system design walkthrough

every Tuesday — each mapped to its archetype so you build

pattern recognition, not answer memorization.

This week: Google Drive / Dropbox.

https://systemdr.systemdrd.com/subscribe

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

Want the complete learning path?

Unlock advanced modules, case studies, and guided exercises.

This is the question that defines:

The surface question sounds manageable. Netflix streams video to 270 million subscribers. How hard can it be to store a file and serve it? The probe underneath is what makes this question a senior filter. The interviewer is not testing whether you know what a CDN is. They are testing whether you understand why naive HTTP file serving collapses at scale, what adaptive bitrate encoding is and why it exists, how a CDN edge network makes cold-start latency irrelevant, and what happens when the most-watched show in the world premieres at 9 PM and 50 million people try to start the same episode simultaneously.

Those four problems — not the basic architecture — are where the round is decided.

For L4 / mid-level: the content storage and delivery pipeline at a high level. For L5 / senior: adaptive bitrate encoding with multiple renditions, CDN edge caching with pre-positioning, and the cold-start problem. For L6 / staff: the encoding pipeline at scale, multi-region active-active CDN strategy, the playback session architecture, quality-of-experience monitoring, and what Netflix actually does differently from a naive CDN deployment.

The Question

“Design Netflix. Users should be able to browse a catalog of movies and TV shows and stream them on demand with high quality and low buffering.”

Common variants:

- “Design YouTube’s video streaming system.”

- “Design Spotify’s audio streaming.”

- “Design Twitch’s live streaming platform.”

- “Design an adaptive bitrate streaming system.”

- “Design the video encoding pipeline for a platform like Netflix.”

The first two are nearly identical to Netflix. Twitch adds a real-time constraint (live, not on-demand) that changes the delivery model but not the encoding fundamentals. Spotify replaces video with audio — smaller files, same adaptive delivery architecture. The encoding pipeline variant focuses specifically on Phase 2 below.

Step 1 — Clarify Before You Draw

Six questions. The first three are load-bearing.

1. On-demand only, or also live streaming? On-demand (Netflix, Spotify) and live (Twitch, live sports) have meaningfully different architectures. On-demand content can be pre-encoded, pre-cached at CDN edges, and optimized offline. Live content has a latency requirement (viewers want near-real-time) that forces a different delivery model. Clarify and scope to on-demand unless told otherwise.

2. What devices must be supported? Smart TVs, mobile (iOS/Android), web browsers, game consoles. This matters because different devices support different codecs (H.264, H.265/HEVC, AV1, VP9) and different DRM systems (Widevine, FairPlay, PlayReady). Acknowledge the codec diversity; don’t try to design the full DRM system in the interview — it’s a separate subsystem.

3. What are the quality and latency SLOs? Netflix targets: playback starts within 2 seconds of pressing play. Buffering events under 0.5% of total play time. 4K HDR delivery available on supported devices. These numbers drive every architecture decision — state them explicitly before drawing anything.

4. What is the catalog size? Netflix has approximately 36,000 titles globally (varies by region). Each title is stored in multiple renditions and formats. State the working assumption: 36,000 titles × 20 renditions × ~4 GB per rendition = ~3 PB of encoded video. This estimate calibrates the storage and CDN design.

5. What scale? 270 million subscribers. Peak concurrent streams: approximately 15–20% of active users simultaneously — roughly 40–50 million concurrent streams. At peak (new season premiere, weekend evening), this spikes significantly. State the peak assumption explicitly.

6. Does the design include recommendations, search, and the catalog UI? These are separate systems (ML recommendation engine, search index, catalog metadata API). Acknowledge they exist; scope the interview to the streaming pipeline — content ingestion, encoding, storage, and delivery. Otherwise you’ll spend 30 minutes on recommendation and never get to the hard part.

Step 2 — Estimate

Working assumptions:

- 36,000 titles × 20 renditions per title = 720,000 encoded files

- Average rendition size: 4 GB (HD, 2-hour movie)

- Total encoded storage: 720,000 × 4 GB ≈ 3 PB of video content

- Metadata storage (titles, posters, descriptions, subtitles): ~5 TB — trivial by comparison - Peak concurrent streams: 50 million

- Average bitrate served: 5 Mbps (mix of HD and 4K streams)

- Peak egress bandwidth: 50M streams × 5 Mbps = 250 Tbps

That 250 Tbps peak egress number is the most important figure in the whole estimate. Netflix is one of the largest sources of internet traffic on the planet — at peak, it accounts for roughly 15% of global downstream internet bandwidth. No single origin infrastructure serves this. CDN edge servers distributed globally are the only viable answer. State this conclusion explicitly from the estimate.

Content ingestion rate: Netflix adds roughly 500–1,000 hours of new content per month. At 20 renditions per title, that’s ~10,000–20,000 encoding jobs per month — a background batch process, not a latency-sensitive path.

Get Access to GitHub Repo

Step 3 — API Design

Four APIs. The streaming API is the non-obvious one.

The senior move here: The manifest_url in the playback start response is the key design signal. You are not returning a video file URL — you are returning a manifest file URL. This distinction is the entire adaptive bitrate streaming architecture. Explain it before moving on.

The heartbeat endpoint is the second senior signal. Netflix does not stream and forget. Every 30 seconds, the player reports back: current position, current quality, buffer health, rebuffer events, estimated bandwidth. This telemetry is the basis for quality-of-experience monitoring, A/B testing new streaming algorithms, and detecting degraded CDN nodes before users notice. Candidates who include the heartbeat signal they’ve thought about the operational layer, not just the happy path.

Step 4 — Data Model

Five stores. Video content itself is not in any of these — it lives in object storage.

titles table — catalog metadata

title_id, title, description, genres[], cast[], director,

release_year, rating, available_regions[], duration_seconds,

thumbnail_url, created_at, updated_at

Sharded by title_id. Regional availability (available_regions[]) drives catalog filtering — a subscriber in Germany sees a different catalog than one in the US because Netflix licenses content per territory.

content_assets table — encoded renditions index

content_id, title_id, rendition_type (4K/1080p/720p/480p/360p),

codec (H264/H265/AV1), bitrate_kbps, file_size_bytes,

storage_uri (S3 path), manifest_uri, duration_seconds,

encoding_status (pending/processing/ready), created_at

The manifest_uri points to the HLS or DASH manifest file in S3 — the index of all segments for this rendition. When the player starts playback, it downloads the manifest first, then requests individual segments.

playback_sessions table — active and recent sessions session_id, user_id, content_id, device_type, started_at,

last_heartbeat_at, current_position_seconds, current_quality,

total_play_time_seconds, rebuffer_count, total_rebuffer_seconds

Not stored in your OLTP database. High-frequency writes (heartbeat every 30 seconds, 50M concurrent sessions = ~1.7M writes/sec). Use Cassandra or a time-series store. Partition by user_id so “resume where I left off” is a single-partition read. Short TTL — you only need the last 30 days of session data for analytics; older data goes to cold storage.

user_watch_history — resume position and completion user_id, title_id, content_id, position_seconds, completed (boolean), watched_at, device_type

This is what powers “continue watching.” Separate from the playback session — a session is live, watch history is the permanent record. Partition by user_id.

CDN content index — not a database table

The CDN’s internal index of what content is cached at which edge location. You don’t design this — it’s the CDN’s internal state. What you do design is the pre-positioning logic: before a major content release (new season of a hit show), Netflix pre-pushes the encoded files to CDN edge servers before playback demand arrives. This is called content pre-warming and it is one of the most important operational patterns in the whole system.

Read more

The standard failure mode: a candidate mentions CAP theorem as a vocabulary signal (”we need to think about the CAP trade-off here”), states the three letters (Consistency, Availability, Partition tolerance), and moves on without connecting it to a concrete decision.

The interviewer writes “mentioned CAP but couldn’t apply it.” The round continues.

Here’s what applying it actually looks like.

What CAP actually says

CAP theorem says: in the presence of a network partition — when some nodes in your distributed system can’t communicate with others — you must choose between consistency and availability. You cannot have both.

Consistency here means: every read returns the most recent write, or an error. Every node agrees on the current state.

Availability means: every request gets a response. It may not be the most recent data, but the system doesn’t error or time out.

Partition tolerance isn’t a choice — it’s a given. If you’re building a distributed system that runs over a real network, partitions happen. Network cables fail. Datacenters lose connectivity. You cannot opt out of partition tolerance. The real choice is always: when a partition happens, do you stay consistent or available?

Subscribe for Payments Walkthrough

Where it actually matters

The question is rarely “should I build a CP or AP system?” That’s too abstract to be useful. The useful version is: for this specific read, how stale can the data be before it causes a real problem?

Some reads tolerate stale data completely. Your Twitter follower count being one minute stale costs nothing. Your Netflix streaming recommendation being 24 hours stale costs nothing. These are candidates for eventual consistency — replicate async, serve locally, accept a brief window of inconsistency.

Some reads cannot tolerate stale data. Your bank account balance must be accurate before a payment is authorized. Your ticket reservation must be current before a seat is sold. These require strong consistency — at the cost of higher latency and potential availability loss during a partition.

The L5 answer isn’t “I’ll use eventual consistency.” It’s: “For the timeline read, I’ll accept eventual consistency — a post appearing 30 seconds late costs nothing. For the payment authorization, I need strong consistency — an incorrect balance check is a real financial loss. These two paths use different consistency models within the same system.”

PACELC: the extension worth knowing

CAP only talks about partition scenarios. PACELC extends the model to the normal case: even without a partition, there’s a trade-off between latency and consistency. If you want every read to reflect the latest write, you need to coordinate across replicas — which adds latency. If you serve from the nearest replica without coordination, you have lower latency but possible stale reads.

Knowing PACELC by name is a mild L6 signal. More importantly, understanding that the consistency/latency trade-off exists even on sunny days is what matters.

The three decisions CAP drives in practice

When you reach the data model step in a design interview, CAP should inform exactly three things:

Replication strategy. Synchronous replication (every write waits for all replicas to confirm) gives strong consistency at the cost of write latency. Asynchronous replication (write confirms when the leader writes, replicas catch up later) gives lower write latency but a brief consistency window.

Read routing. If you route reads to the leader only, you always get the latest data. If you route reads to any replica, you get lower latency but potentially stale data. Pick based on what each read is for.

Conflict resolution. When two nodes accept writes for the same key during a partition, you have a conflict. Last-writer-wins, vector clocks, CRDTs, operational transforms — each is a different answer to the same CAP-induced conflict problem.

The engineers who use CAP well in interviews don’t mention it as a signal. They use it as a decision tool. “For the payment authorization read, I need consistency over availability — I’ll route to the leader and accept higher latency.” That sentence is CAP applied correctly. It doesn’t require saying “CAP” at all.

CTA: The Stripe Payments walkthrough (paid post #2) covers the consistency decisions in a payment system end-to-end — exactly where strong consistency is required, exactly where eventual is acceptable, and why.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

This is the question that defines the real-time messaging archetype. Ten questions in the question bank are variants of it — Slack, Discord, Zoom, Twitter Spaces, iMessage, Facebook Messenger, Google Chat. They share a spine: a long-lived connection problem, a delivery semantics problem, and a presence problem. Get fluent with all three and you can answer any messaging interview you’re handed.

The surface question looks simple: two people want to send each other messages. The probe underneath is anything but. Interviewers use this question because it exposes how candidates think about distributed systems under failure — specifically what happens when the recipient is offline, when the network drops mid-message, when the same message arrives twice, and when a user has five devices. Those four failure modes, and your response to them, are where the round is decided.

For L4 / mid-level: the basic chat flow and message storage. For L5 / senior: delivery semantics under unreliable networks (at-most-once, at-least-once, exactly-once), presence at scale, and offline message handling. For L6 / staff: the multi-device consistency model, group message fan-out at WhatsApp’s scale (2 billion users), end-to-end encryption architecture, and what happens when a message is delivered to 256 group members across 12 time zones while half of them are offline.

The Question

“Design WhatsApp. Users should be able to send messages to each other in real time. Messages should be delivered even when the recipient is temporarily offline.”

Common variants:

• “Design Facebook Messenger.”

• “Design iMessage / Apple Messages.”

• “Design Slack’s messaging core.”

• “Design a real-time chat system.”

• “Design the messaging layer for [our product].”

All five are the same architecture. Slack adds channels and threads; the delivery model is identical. iMessage adds end-to-end encryption; the transport is identical. Discord adds voice and server-based channels; the one-to-one messaging core is identical.

Step 1 — Clarify Before You Draw

Six questions. Two of them are load-bearing for the entire design.

1. One-to-one only, or also group chats? One-to-one is the simpler problem. Group chats add fan-out — sending one message to N recipients — which at WhatsApp’s scale means up to 256 recipients per group. State which you’re designing for. For L5+: design for both, but start with one-to-one and explicitly extend.

2. What are the delivery guarantees? This is the load-bearing question. Three options:

• At-most-once: messages might be lost but never duplicated. Fine for ephemeral signals (typing indicators). Terrible for chat.

• At-least-once: messages are definitely delivered but might be delivered more than once. The receiver handles deduplication. Acceptable for most chat systems.

• Exactly-once: messages are delivered exactly once, regardless of retries. Theoretically ideal. In practice, you can approximate it with idempotency keys and deduplication at the receiver — but you cannot achieve it perfectly across an unreliable network. Saying “exactly-once is impossible in a distributed system” out loud is a senior signal.

WhatsApp and most production systems implement at-least-once delivery with client-side deduplication. State this explicitly.

3. What devices does each user have? Multiple devices per user (phone, tablet, web, desktop) massively complicates the model. A message sent to a user needs to land on all their active devices. On which device does the “read receipt” trigger? Clarify this early.

4. Offline handling — how long do you store messages for an offline recipient? If a recipient is offline for 30 days, do their messages accumulate on your servers? Most production systems store for 30 days and drop after that (with notification to sender). Clarify the retention window.

5. End-to-end encryption? E2EE (like WhatsApp’s Signal Protocol implementation) means the server cannot read message content — it only stores encrypted ciphertext and routing metadata. This changes the data model significantly. State whether you’re designing with E2EE or not. For L5: acknowledge it exists and where it fits. For L6+: explain the key exchange flow.

6. What scale? 2 billion monthly active users is WhatsApp’s actual scale. For the interview, pick a working number: 500M DAU, 100 billion messages per day (WhatsApp’s reported figure as of its scale). These numbers drive your storage and throughput estimates.

Step 2 — Estimate

Working assumptions:

• 500M daily active users

• 100 billion messages per day = ~1.16 million messages per second average, ~5M/sec peak

• Average message size: 100 bytes (text only), 500 bytes with metadata

• 30-day message retention for offline recipients

• 1 billion messages stored at any moment (roughly 1% of daily volume is “pending delivery”)

• Media (images, video, voice): handle separately via object storage (S3 / CDN pre-signed URLs); only metadata and a pointer lives in the chat system

Storage for messages: 100B messages/day × 500 bytes × 30 days retention ≈ 1.5 PB. This is your “hot” storage — messages waiting to be delivered or recently delivered. After 30 days, messages drop off the hot store. Delivered messages can be stored client-side and expunged from the server (this is exactly what WhatsApp does — server deletes after delivery confirmation).

Connection state: 500M users × ~30% concurrently connected = ~150M concurrent WebSocket connections. At 64KB per connection socket buffer that’s roughly 9.6 TB of connection memory across your fleet. This is one of the hardest scaling problems in messaging — the number of open connections.

Write throughput: 1.16M messages/sec average into a message store. This rules out single-node anything. You need a distributed message queue and a sharded persistence layer.

Get Access to GitHub Repo

Step 3 — API Design

Four endpoints. The real-time delivery is not REST — it’s a persistent connection.

WebSocket: wss://chat.whatsapp.com/connect

Auth: Bearer token in Upgrade request headers

Purpose: The long-lived connection for receiving messages and sending keep-alives. All message delivery happens here.

On connect: server sends any pending (undelivered) messages accumulated while the client was offline.

The senior move on the API step: Name the Idempotency-Key and message_id in the same breath. The message_id is client-generated before the send — if the client retries because it didn’t receive an ack, the server detects the duplicate via message_id and does not re-queue. The Idempotency-Key is the HTTP-level dedup. Both are necessary: the HTTP key handles transport-level retries, the message_id handles application-level deduplication across devices and reconnections.

Saying that distinction out loud — two levels of deduplication for two different failure modes — is the L6 signal on this question.

Read more

Learn System Design with System building, Subscribe Hands On coding course - LogStream

There’s a version of the system design interview where the candidate designs Twitter. The entire Twitter. Timeline, search, notifications, recommendations, ads, analytics, direct messages.

At the 40-minute mark they’re still drawing boxes. They haven’t gone deep on anything. The interviewer writes “breadth over depth, no clear prioritization” on the scorecard.

This is the most common failure mode among technically strong candidates, and it has nothing to do with technical knowledge. It’s a scoping problem.

Here’s the discipline that fixes it.

The negotiation in the first five minutes

Most candidates use the first five minutes to ask clarifying questions. How many users? What’s the read:write ratio? Does this need global availability?

These are fine questions. They’re also generic — they could be asked for any question. They don’t signal to the interviewer that you understand how to manage scope.

The candidates who score well on problem scoping don’t just ask questions. They propose scope.

“There are several interesting subsystems here: the timeline, search, notifications, the recommendation algorithm, and the ad serving layer. I’m going to focus on the timeline and the fan-out architecture. I’ll acknowledge the others exist and sketch where they’d connect, but I won’t design them in detail. Does that direction work for you?”

This is different from asking questions. You’re proposing what you’re going to design and explicitly not design, and you’re inviting the interviewer to redirect if they want something different.

Most interviewers will say yes. Some will redirect you: “Actually, I’m more interested in the fan-out problem for group chats specifically.” This is useful information you would not have gotten without proposing scope first.

Subscribe for WhatsApp Walkthrough

Why the pressure to cover everything exists

The instinct to design everything is understandable. The interview is evaluating your technical breadth, right? If you only design one component, won’t the interviewer think you don’t know the rest?

This misunderstands what the interview is evaluating.

Interviewers at L5+ levels are not checking whether you’ve memorized the architecture for every subsystem of Twitter. They know you’re familiar with notifications and search — you work as a software engineer. What they can’t infer from your resume is whether you can identify the hardest distributed systems problem in a question, scope down to it, and go deep enough to demonstrate real understanding.

Designing eight systems shallowly proves you’re familiar with eight systems. Designing one system deeply proves you can think through the hard parts of a complex problem. The second is what they’re scoring.

How to choose what to scope in

The right component to go deep on is the component with the most interesting distributed systems problem. Not the component you know best. Not the component that feels safest. The component where the answer is genuinely non-obvious.

For Twitter: the fan-out problem is more interesting than the user profile service. The timeline cache architecture is more interesting than the follow/unfollow API. Go where the hard problem lives.

A useful test: which component, if I described it at a surface level, would the interviewer immediately probe deeper on? That’s the component to start with.

What to do with the components you’re not designing

You don’t ignore them. You acknowledge them.

“Notifications would follow a standard fan-out-on-write pattern with push to APNs/FCM for mobile and WebSocket for web, similar to what we discussed for the timeline. I’m not going to design it in detail, but the interesting problem there is the delivery guarantee under failure — we’d need at-least-once delivery with client-side dedup.”

One sentence that shows you understand the problem, the standard solution, and the interesting edge case — without spending five minutes on a full design. This signals breadth without consuming depth time.

The specific framing that works

After the estimation section, before drawing anything, say this out loud:

“Before I draw the architecture, I want to lock scope. I’m going to go deep on [component X] because that’s where the interesting distributed systems problem is. I’ll acknowledge [components Y and Z] exist and show where they connect, but I won’t design them fully unless you’d like me to. Does that work?”

The explicit scope lock serves two purposes. It sets expectations so the interviewer isn’t waiting for you to cover components you’ve already decided to skip. And it gives the interviewer one last opportunity to redirect before you’ve committed 30 minutes to the wrong area.

After this moment, the scope is locked. Don’t drift. If you finish the deep dive early, go deeper on the component you chose — don’t add new components to fill time.

The uncomfortable truth about breadth

Demonstrating breadth is valuable. Demonstrating it through shallow coverage of many components is not the right way.

The right way: show breadth through the quality of your acknowledgments. When you mention a component you’re not designing and you correctly name the problem it has and the standard approach for solving it, you’ve shown breadth in one sentence. Compare that to spending five minutes on a shallow design of the same component — same signal, five minutes cheaper.

Scope discipline isn’t about knowing less. It’s about deploying what you know efficiently enough to demonstrate depth where it matters.

CTA: Tuesday’s paid post is the full WhatsApp walkthrough — including how to scope it correctly when the question says “design a messaging system” and you have 50 minutes.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

Curious how this works in real systems?

The paid lessons cover scalability, optimization, and real-world engineering patterns.