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

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.

This is the question that defines the marketplace and matching archetype. Ten questions in the question bank are variants of it — DoorDash delivery, Airbnb booking, Tinder matching, parking reservation, surge pricing, ride-share fraud. They share a spine: a supply side, a demand side, a location component, and a real-time matching requirement. The architecture that works for Uber dispatch, with minimal modification, works for all ten.

The surface question — “design Uber” — is a 4-hour answer. Interviewers narrow it deliberately: “design the dispatch system,” “design how a driver gets matched to a rider,” “walk me through what happens between the rider hitting ‘Request’ and the driver getting a notification.” All three collapse to the same probe: how do you find the nearest available supply in real time, at scale, without burning down your database on every request?

The answer involves a data structure most candidates haven’t touched since their algorithms course: geospatial indexing. Specifically, quadtrees or geohashing — and knowing which one and why is the senior signal.

For L4 / mid-level: describe the matching flow and a naive approach. For L5 / senior: articulate the geospatial indexing choice with its trade-offs. For L6 / staff: the consistency model across supply/demand state, the surge pricing data flow, multi-city scaling, and what happens when a driver’s GPS signal drops.

The Question

“Design the Uber dispatch system. A rider requests a ride. The system finds nearby available drivers and assigns one to the rider.”

Common variants:

• “Design DoorDash / UberEats food delivery dispatch.”

• “Design Lyft’s matching system.”

• “Design a system to match drivers to delivery orders in real time.”

• “Design the driver-to-rider matching at Uber.”

All four are the same architecture. DoorDash has one additional dimension — the restaurant (a fixed supply point instead of a moving one) — but the matching logic is identical.

Step 1 — Clarify Before You Draw

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

1. What does “dispatch” include — match only, or also route and surge? Dispatch in the narrow sense is “find a driver and assign them to a rider.” Routing (which road to take) is a separate system (Google Maps API or in-house). Surge pricing (dynamic fare) is another separate system. Clarify scope explicitly. Design the matching layer; acknowledge the others exist.

2. How many active drivers? What’s the geography — one city or global? Active drivers in a single city: tens of thousands. Globally: millions. This shapes whether your geo-index fits in memory on one machine or needs distribution. For a US metro at peak, 10,000–50,000 active drivers is a reasonable working number. Global scale: 5–10M.

3. How frequently do drivers update their location? Every 4–5 seconds is typical. This is a high-frequency write stream — 50,000 drivers × 1 write/4s = ~12,500 writes/sec in one busy metro. Globally: millions of writes/sec. State this number; it drives the design of the location ingestion layer.

4. What’s the matching latency SLO? A rider hits “request” and expects a driver to accept within 30–60 seconds. The matching decision itself should happen in milliseconds — sub-100ms for the initial candidate selection. If it takes 5 seconds to find a candidate, the experience breaks.

5. Can a driver be matched to multiple requests simultaneously? No — a driver has one state: available or not. This is the consistency problem at the heart of the question. Two riders cannot be dispatched to the same driver. The system that manages this state is load-bearing.

6. What failure modes matter most? Driver goes offline mid-trip. GPS signal drops. Driver declines the match. Rider cancels after match. Each one requires a state machine transition. State the three most important ones out loud.

Step 2 — Estimate

Working assumptions for a single large metro deployment:

• 50,000 active drivers at peak

• 200,000 ride requests per hour at peak = ~55 ride requests/sec

• Driver location update: every 4 seconds, so 50,000 / 4 = 12,500 location writes/sec

• Matching query: for every ride request, find all drivers within ~2 km radius

• Average matching candidate set: 20–50 drivers

• End-to-end dispatch latency target: < 100ms for candidate selection, < 30s for driver acceptance

Location data per driver per update: ~100 bytes (driver_id, lat/lng, timestamp, status).

Writes: 12,500/s × 100 bytes ≈ 1.25 MB/s. Trivial for a single machine.

If global (5M drivers): 5M / 4 = 1.25M writes/sec. Serious — needs distributed location ingestion. But for this walkthrough, start with the single-metro case and note the global extension.

The geo-index in memory for 50,000 drivers: 50,000 × 100 bytes = 5 MB. Fits entirely in memory on a single machine. This insight — that the active driver set for one city is tiny — is what enables the in-memory geo-index approach.

Get Access to GitHub Repo

Step 3 — API Design

Three endpoints. The first is rider-facing, the second is driver-facing, the third is the internal matching call.

The senior move on location updates: note that the driver app batches and sends at 4-second intervals, not on every GPS tick (which might be 1-second intervals). Batching reduces write load by 4x and extends driver battery life. Saying this out loud — that the client has a role in write amplification — is an insight most candidates miss.

heading and speed_mps in the location update. Junior candidates send only lat/lng. Senior candidates send velocity vector too. Why: ETA estimation to a pickup point requires knowing not just where the driver is but which way they’re going and how fast. A driver 500m away facing the wrong direction on a one-way street is further than a driver 700m away pointed at you. The heading/speed fields feed the ETA model.

Step 4 — Data Model

Four stores. The geo-index is the unusual one.

drivers table — source of truth for driver state

driver_id, name, vehicle_type, license_plate, rating_avg, total_trips,

current_status (ENUM: available/on_trip/offline/suspended),

current_lat, current_lng, last_location_update, created_at

Sharded by driver_id. The current_status and current_lat/lng columns are updated frequently — this is the consistency-critical state. More on that in Step 6.

rides table — the ride state machine

Ride state machine: searching → matched (driver found) → accepted (driver acknowledged) → driver_en_route → arrived → in_progress → completed | cancelled

Any state can transition to cancelled. The driver_id is only set at the matched transition. If a driver declines, status reverts to searching and the matching process re-runs.

location_history — time series store

Not your OLTP database. Location events are time-series data: (driver_id, lat, lng, timestamp, heading, speed). At 12,500 events/sec, that’s 1 billion events/day in one metro. You don’t store this in Postgres. You use a time-series database (InfluxDB, TimescaleDB, Cassandra with a time-ordered key) or push to a data lake for analytics.

The hot query (”where is this driver right now?”) hits the geo-index, not this table. This table is for analytics, replay, and dispute resolution (”I was at X at time T — prove it”).

driver_geo_index — the in-memory geo-index

This is the heart of the system. Not a SQL table. An in-memory spatial index that answers “which drivers are within radius R of point (lat, lng) in sub-millisecond time.”

Two real options: quadtrees or geohashing. This is Step 6’s deep dive.

Read more

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

There are 52 questions in the FAANG system design question bank. Engineers preparing for FAANG-tier interviews often drill them one by one: design Twitter, then design Uber, then design WhatsApp, then design Stripe.

This is the wrong approach. Not because the questions don’t matter — they do. But because drilling 52 individual questions treats each one as unique when most of them are the same question with a different surface.

Here’s what I mean.

The 10 underlying problems

Every system design question is fundamentally an instance of one or more of these:

Fan-out under load — how do you efficiently deliver one write to many readers? Twitter’s feed, Instagram’s feed, TikTok’s feed, Slack’s channel messages, notifications. All the same problem. The celebrity/large-group edge case appears in all of them.

Inventory reservation — how do you prevent two users from claiming the same unit simultaneously? Airbnb’s booking, ticket booking, parking lot reservation. All the same atomic-claim-under-contention problem. The same FOR UPDATE SKIP LOCKED pattern solves all three.

Subscribe for Question Walkthrough

Delivery semantics under failure — what happens when the network drops in the middle of a message delivery? WhatsApp, Slack, notification services, task queues. All wrestling with at-least-once vs exactly-once and the FLP impossibility argument.

Geospatial proximity — how do you efficiently find nearby things in real time? Uber’s driver matching, Yelp’s restaurant search, Tinder’s candidate discovery, DoorDash’s Dasher assignment. Geohashing or quadtrees. Same index. Different shape of data.

Time-series at scale — how do you store and query data that’s ordered by time and written at massive volume? Metrics monitoring, log aggregation, ride history, payment history. Same write-optimized, rollup-tiered architecture.

Pre-computation vs on-demand — when do you compute the answer at write time vs query time? Feed ranking, typeahead, recommendation engines. Same trade-off: store more, compute less per query.

Adaptive delivery — how do you serve the right quality given uncertain network conditions? Netflix streaming, Spotify, live video, file transfer. Same ABR pattern. Different media format.

Content-addressed storage — how do you store large binary objects efficiently across millions of users? Dropbox, iCloud Photos, any file storage product. Same chunking, hashing, deduplication pattern.

Global rate control — how do you enforce a limit across a distributed fleet of servers? Rate limiters, budget pacing in ad systems, quota enforcement. Same sliding window counter in Redis.

Fraud via relationship patterns — how do you detect bad actors whose individual actions look legitimate? Payment fraud, ride-share fraud, ad click fraud. Same two-layer architecture: streaming rules for velocity, graph analysis for network patterns.

What this changes about preparation

Once you see the underlying patterns, the preparation strategy changes.

Instead of drilling 52 individual questions, drill 10 problem types. When you understand fan-out deeply — the write amplification, the celebrity threshold, the hybrid approach — you can answer Twitter’s timeline, Instagram’s feed, TikTok’s FYF, and Slack’s channels as variants of the same problem. The surface details change. The architecture doesn’t.

This is why the question bank is organized by archetype, not by company. Twitter’s timeline is filed under “Social Feed” alongside Instagram, TikTok, and Reddit. Uber is filed under “Marketplace & Matching” alongside Airbnb, Tinder, and DoorDash. The point is to make the pattern visible.

The test you can run right now

Take any two questions from your preparation list. Can you identify the one or two underlying patterns they share? If yes, drilling one deeply makes the other easier. If no — reply to this post and I’ll map it for you.

The engineers who consistently pass at L5 and L6 don’t have 52 memorized answers. They have 10 deeply understood patterns and the ability to apply them to a question they haven’t seen before.

That second skill is what the interview is actually testing.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

Want the complete learning path?

Unlock advanced modules, case studies, and guided exercises.

The version most interviewers ask is not “design Twitter” — that’s a 4-hour question. They ask “design the Twitter home timeline” or “design the news feed for [our product]” or “design the part of [X] that shows posts from people you follow.” All of these collapse to the same probe: how do you serve a feed for a user whose followed set has wildly variable size and post rate, while keeping the feed fresh?

For L4 / mid-level the bar is articulating one approach (fanout-on-write) and walking it cleanly. For L5 / senior, the probe is the trade-off between fanout-on-write and fanout-on-read, and the realization that production systems do both depending on the user. For L6 / staff, the probe is hot-user handling, ranking, and the operational story for a system that ingests millions of writes per second and serves billions of feed reads.

The Question

“Design the Twitter home timeline. A user opens the app and sees a feed of recent posts from the people they follow, sorted appropriately. Posts can be original tweets, retweets, or replies.”

Common variants:

• “Design Instagram’s feed.”

• “Design Facebook News Feed.”

• “Design the LinkedIn home page.”

• “Design Reddit’s front page.”

• “Design the TikTok For You feed.”

The first four are direct equivalents. TikTok For You is almost the same — but with one critical difference: it’s not a follow-graph feed, it’s a recommendation feed. The architecture is similar; the candidate generation is different. Note this if asked.

Step 1 — Clarify Before You Draw

Six questions. The first three matter most.

1. Are we ranking or just chronological? Old Twitter was reverse-chronological. Modern Twitter is ranked. This is the single biggest variable. Chronological is far simpler — sort by timestamp, done. Ranked introduces a scoring system, a feature pipeline, and probably an ML model. State which one you’re designing for explicitly. If unclear, design ranked — it’s the harder and more realistic version.

2. What’s the active user count? What’s the average follow count? What’s the maximum? The numbers determine the architecture. 100M daily active users with average follow count 200 looks different from 500M DAU with average follow count 500. The maximum follow count is the more decisive number — it’s the long-tail celebrity problem in disguise. State explicit numbers.

3. What’s the read-to-write ratio? Always lopsided in social feeds, but how lopsided matters. 100:1 means you have lots of writes; 1000:1 means you can afford to do work on the write path. State the ratio; it justifies fanout-on-write later.

4. How fresh? Real-time, or 5-minute staleness OK? Real-time means push. Stale-OK means pull or hybrid. Most production feeds tolerate seconds-to-minutes of staleness; saying “I’d target 5-second p99 freshness” is a senior signal.

5. What goes in the feed besides original posts? Retweets count as posts, generally. Replies usually don’t appear in the home timeline by default (only on the conversation thread). Trending topics, ads, suggested follows, “in case you missed it” pulls — all of these are injected into the feed in production. Acknowledge this exists; don’t try to design it all.

6. What’s the SLO for feed load? Typical: p50 < 200ms, p99 < 500ms for the API. The user opens the app and the timeline has to be there. State the number; it drives caching.

Step 2 — Estimate

Working assumptions for the rest of this walkthrough:

• 500M daily active users (DAU)

• Each user reads their feed ~5 times/day on average → 2.5B feed reads/day → ~30K reads/sec average, peaking at 200K

• Each user posts ~0.2 times/day on average → 100M posts/day → ~1,200 posts/sec average, peaks at ~10K

• Average follow count: 200 (median is much lower; mean is dragged up by power users)

• Maximum follow count: 5,000 (for normal users; verified accounts can exceed)

• Maximum follower count: 100M+ (for celebrities — this is the asymmetry that breaks naive designs)

• Posts retained in timelines: roughly 1,000 per user (older items can be paginated in on demand)

Storage:

• Posts table: 100M posts/day × 365 days × 5 years × 1 KB ≈ 180 TB

• Timeline cache (precomputed timelines): 500M users × 1,000 posts × 200 bytes/entry ≈ 100 TB

• Follow graph: hundreds of billions of edges, but each edge is small (~30 bytes) → ~3-5 TB

The timeline cache is the unusual one. It’s bigger than your hot OLTP and lives in a different system (typically Redis, Memcached, or a custom in-memory store). When a senior candidate names this layer separately from the posts store, you know they’ve built something like this.

Read bandwidth:

• 200K reads/sec × 1,000 timeline entries × 200 bytes ≈ 40 GB/s

• This is what the timeline cache absorbs — the posts table never sees this traffic.

Get Access to GitHub Repo

Step 3 — API Design

Three endpoints. The first one is the headline.

Pagination is cursor-based, not offset-based. Offset (page=3, per_page=20) is broken at scale because the data shifts beneath you — by the time you fetch page 3, new posts have arrived and pushed everything down. Cursors (an opaque token encoding a position in the feed) are immune to this. Saying “cursor-based, never offset-based for feeds” is a senior signal.

ranked_at in the response is the time the timeline was scored. Useful for client-side caching (”don’t re-fetch for 30 seconds”) and for debugging staleness reports. Most candidates omit this. Including it is a small but real senior tell.

Read more

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

Most engineers preparing for senior-level interviews have a vague sense that “L6 answers go deeper.” This is both true and useless as preparation advice. Deeper in what direction? Deeper by how much? What specifically changes?

refer basics here - load balancing 101 -

Here is what specifically changes.

L4 → L5: from “what” to “why”

An L4 answer describes the architecture. An L5 answer defends it.

At L4, the bar is: can you run a framework, estimate sensibly, and produce a coherent design with read and write paths? That’s it. Interviewers are checking whether you know the building blocks.

At L5, the bar is: can you justify your decisions? When the interviewer asks “why did you partition by recipient_id instead of sender_id?”, the L4 candidate says “that’s the standard approach.” The L5 candidate says “because the hot query is ‘give me all pending messages for user X’ — partitioning on the read pattern means that query hits one shard. If I partitioned by sender, delivering to user X requires querying every node.”

The transition from L4 to L5 is the transition from “stating decisions” to “reasoning about decisions.” Same architecture. Different explanation.

Subscribe for Question Walkthrough

L5 → L6: from design to operation

An L5 answer designs a system that works. An L6 answer designs a system that works and describes how you’d know if it was failing.

L6 adds three things that L5 almost never has:

SLOs with monitoring signals. Not “the API should be fast.” “I’m targeting p99 < 100ms for the feed read. The metric I’d alert on is cache hit ratio dropping below 90% — that’s the leading indicator that Postgres load is about to spike.”

Failure modes named and partially addressed. Not “we’d add monitoring.” “The failure mode here is the thundering herd when the Redis node recovers — if we don’t add jitter to the retry, every failed request retries simultaneously and we bring Redis down again the moment it comes back up.”

The operational reality of trade-offs. L5 says “consistent hashing handles node failure gracefully.” L6 says “consistent hashing with virtual nodes handles it, but I’d still want an active health check every 5 seconds and a circuit breaker so that if a node is responding slowly rather than failing hard, we stop routing to it before the tail latency affects users.”

The transition from L5 to L6 is the transition from “designing for the happy path” to “designing for the failure path.”

L6 → L7: from system to organization

L7 is the level where the interview stops being about a single system and starts being about the relationship between systems — and the teams that build them.

L7 adds:

Build vs buy decisions with economic reasoning. Not “we’d use Kafka.” “For this use case, Kafka is the right call — the producers and consumers have different scale characteristics and we want replay capability. But if we’re a 20-person company, the operational overhead of Kafka is probably not worth it; I’d use SQS and revisit when the team can support it.”

Organizational implications. “This architecture creates a hard dependency between the payments team and the notifications team. I’d extract the notification contract into a shared schema owned by a platform team to prevent that coupling from slowing down both teams’ deploy cadence.”

Platform thinking. Not “how do I build this feature” but “how do I build this such that 10 teams can build features on top of it without coordinating with me.”

The pattern

Each level adds a type of thinking, not just more of the same thinking.

L4: knows the vocabulary. L5: can reason about trade-offs. L6: thinks about failure, operations, and monitoring. L7: thinks about organizations, economics, and platforms.

If you’re targeting L5, make sure you can answer “why did you make that choice?” for every major decision. That’s the bar.

If you’re targeting L6, make sure every design decision has three parts: what you chose, why you chose it, and what would change your mind.

If you’re targeting L7, make sure you can talk about one decision in terms of its organizational and economic implications — not just its technical ones.

Paid subscribers get a full system design walkthrough every Tuesday.

This week: Stripe Payments — the idempotency key problem most engineers miss.

The paid posts go deeper on the Senior vs Staff distinction for each specific question — here’s what the L5 answer looks like, here’s what L6 adds, here’s the exact phrasing that signals each.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

Want the complete learning path?

Unlock advanced modules, case studies, and guided exercises.

Subscribe Now.. Here’s what’s included:

→ Every Tuesday paid walkthrough — one full named-question answer every week, calibrated to L4–L7. 52 posts per year.

→ All drill cards — single-page PDFs for each question, designed to be re-read the morning of your interview

→ The full paid archive — every walkthrough ever published, available immediately

→ Framework cheatsheets — estimation numbers, API design patterns, trade-off communication, scaling decisions

→ Discord community — #ask-the-author, mock interview partners, #offers-landed

This is the question that filters senior from staff in money-movement loops. The surface of the question — “design a payments processor” — looks ordinary. The probe underneath is one of the few places in system design interviews where being wrong has audit-trail consequences in production. Interviewers know this, which means they don’t accept the kind of hand-waving that flies on a feed-design question. You either understand idempotency, ledgers, and double-entry, or you don’t. The answer reveals it within five minutes.

If you are interviewing at Stripe, Block, Adyen, PayPal, Robinhood, Coinbase, or any fintech doing real money movement — this is the question. If you’re at FAANG-tier companies whose products handle payments (Amazon, Apple, Google), expect a variant. The frame is always the same: a customer initiates a payment, the system has to debit one party and credit another, and every single step has to be reconcilable, retryable, and auditable.

For L4 / mid-level the bar is the surface design. For L5 / senior, the probe is idempotency keys and the retry semantics around them. For L6 / staff, the probe is the ledger, double-entry consistency, and what happens when the upstream bank says yes-then-no.

The Question

“Design a payment processing service like Stripe. Customers (merchants) integrate your API to charge their end-users’ credit cards. The service handles the full flow: take card details, authorize the charge with the card network, settle the funds, and notify the merchant of the outcome.”

The question is rarely asked exactly this way. Common variants:

- “Design the core payment flow at a payments processor.”

- “Design a system to process credit card charges.”

- “How would you build the part of Stripe that charges a card?”

- “Walk me through what happens between stripe.charges.create() and money landing in the merchant’s account.”

All four are the same question. Don’t be thrown by the framing.

Step 1 — Clarify Before You Draw

Five questions before you draw anything. Each one is loaded.

1. Synchronous or asynchronous API? The merchant calls your endpoint and waits — or — the merchant gets a 202 Accepted and a webhook later? This single question determines half the architecture. Synchronous means your API call blocks on the card network round-trip (200ms–2s of bank latency on the hot path). Asynchronous means you queue the work and notify via webhook. Most production processors offer both modes; the synchronous mode is what merchants reach for first because it’s easier to integrate.

2. What payment instruments? Cards only, or also bank transfers, wallets, and BNPL? Pin this down. Cards only is a different design from “any payment method.” Cards have card networks (Visa/Mastercard/Amex). Bank transfers go through ACH (US), SEPA (EU), UPI (India), and have settlement windows of hours to days. BNPL (Klarna/Afterpay) involves a credit decision. Scope to cards for the core walkthrough; mention that a real system extends to other rails.

3. Are we issuing the cards, or just accepting them? Issuing cards (like Stripe Issuing or Cash App’s debit card) is a totally different system — you’re now responsible for card production, fraud on outbound spend, and chargebacks against your own balance. Accepting is what Stripe Payments does and what most candidates mean. Confirm scope explicitly.

4. Single currency or multi-currency? Multi-currency adds an FX layer, which adds rate-locking semantics (”the customer saw $20, but settle in EUR at what rate?”) and accounting complexity. Most candidates assume USD-only. State the assumption out loud.

5. What’s the SLO? Payment APIs typically target p99 < 500ms for the synchronous flow. And 99.99% availability — payments are revenue, downtime is direct loss for every merchant on the platform. State both numbers explicitly. They drive every later decision.

If you ask all five, you’ve already separated yourself from 80% of candidates. Most jump to drawing.

Step 2 — Estimate

Working assumptions for the rest of this walkthrough:

• 10,000 transactions per second at peak. (Stripe processes more than this; pick a number

• with a buffer.)

• - 100 million transactions per day average; 500 million on peak shopping days.

• - Average ticket: $50. So daily payment volume ~$5B at average, ~$25B at peak.

• - 99.99% availability target = 52 minutes of downtime allowed per year.

• - p99 latency target: 500ms for the synchronous charge endpoint.

Storage:

- Each transaction record is roughly 2 KB after enrichment.

- 100M/day × 365 = 36.5B transactions/year × 2 KB = ~73 TB/year.

- Retention: 7 years for financial records (PCI/regulatory). 7 × 73 = ~500 TB total.

This is big but not unprecedented. The implication: your transactional store is sharded relational (Postgres, Spanner, CockroachDB) and your archive is cold object storage with a hot/warm/cold tier. You won’t keep 7 years in your hot OLTP path.

Network: 10K tps × 2 KB = 20 MB/s. Trivial.

External dependencies — this is the unusual one for this question. You’re round-tripping to:

- Card networks (Visa, Mastercard) for authorization. ~200ms typical, can spike to 2s.

- Acquiring banks for settlement. Async; settlement is a batch process.

- Issuer banks for fraud signals. Sometimes inline, sometimes async.

- Fraud / risk services (could be in-house or external like Sift). ~50ms inline.

- Webhook delivery to merchants. Async, fire-and-forget with retry.

The interviewer will probe this list. Knowing the names of these systems is what separates a senior who has thought about payments from a candidate who’s read one blog post.

Get Access to GitHuB Repo

Step 3 — API Design

Three endpoints. The first one is where the round is decided.

The senior move on this step: name the Idempotency-Key header out loud and explain why it’s there. Say something like: “Charging a card is the highest-stakes API call most companies ever make. Network failures, retries, double-clicks — all of these can cause the merchant’s code to call our endpoint twice with the same intent. We have to detect that and return the cached response instead of charging twice. This is what the Idempotency-Key header does.”

If you say that sentence in a Stripe interview, you’ve passed the first probe. If you don’t mention

idempotency by minute 10 of this question, you fail at minute 30 when the interviewer asks:

“What happens if the merchant’s code retries this call?”

Use integer cents, not floats. I’m calling it out because every junior candidate reaches for float for currency. Floating-point math has rounding errors. $0.10 + $0.20 ≠ $0.30 in IEEE 754. In production this causes accounting drift that takes weeks to find. Integer cents (or smaller — Stripe internally uses millicents for some flows) is the only correct answer. Saying this out loud is another senior signal.

Step 4 — Data Model

The OLTP record for the API call. Optimized for point lookups by id and by idempotency key.

Read more

The first type doesn’t know what consistent hashing is. The second type knows the definition but can’t explain why modulo hashing fails or what problem consistent hashing actually solves.

The second type fails more often. Knowing the name without the reasoning is worse than knowing nothing, because it telegraphs that you’ve memorized vocabulary rather than understood the underlying problem.

Here’s the underlying problem.

The naive approach: modulo hashing

You have 4 servers and a cache key. You run hash(key) % 4 and get a server number. Simple. Fast. Evenly distributed.

Now one of your 4 servers dies. You have 3 servers. Every single key in the system now maps to a different server, because hash(key) % 3 gives completely different results than hash(key) % 4.

Your cache hit rate drops to near zero. Every miss hits the database. Your database falls over. This is a real production incident pattern.

Same problem in reverse: you add a fifth server to handle load. Every key remaps. Every cache entry is now on the wrong server. The cache is empty until it warms up. If you’re adding a server because you’re under load, this is the worst possible time to invalidate your entire cache.

Subscribe for Question Walkthrough

The consistent hashing solution

Consistent hashing puts both servers and keys on an imaginary ring numbered 0 to 2³². To find which server owns a key: hash the key, find its position on the ring, walk clockwise until you hit a server.

When a server is added or removed, only the keys between the new server and its predecessor on the ring need to move. For N servers, adding or removing one server moves approximately 1/N of the keys. Not all of them. 1/N.

That’s the entire point. The damage from topology changes is contained.

Virtual nodes: the production detail

Naive consistent hashing has a problem: if you hash 4 server IDs onto a ring, they won’t land evenly spaced. Some servers end up owning much more of the ring than others. When one server dies, all of its load dumps onto a single neighbor — the one clockwise from it.

Virtual nodes fix this. Instead of placing each server once on the ring, you place it 100–200 times (with different hash inputs like server1-0, server1-1, server1-2...). Each physical server now has 100–200 positions spread around the ring. Load is distributed evenly. When a server dies, its load spreads across every other server, not just one neighbor.

Why this matters in an interview

Consistent hashing shows up in at least 8 of the 52 most common system design questions: distributed caches, rate limiters, database sharding, CDN routing, load balancers, distributed file systems.

When you say “I’d shard by user ID” without specifying how, you’re leaving a gap the interviewer is likely to probe. When you say “I’d use consistent hashing with 150 virtual nodes per server to prevent the hot-neighbor problem on topology changes” — that’s the L5 signal for any infrastructure question.

The rule: anytime you’re distributing data across multiple nodes, consistent hashing is worth naming explicitly. Even if it’s not the exact implementation, mentioning it signals you understand that modulo hashing breaks under real operational conditions.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

Want to explore this topic further?

The paid version includes detailed walkthroughs, bonus resources, and hands-on exercises.

This is the question that gets butchered more than any other in system design prep. Most resources hand you a 5-minute toy answer suitable for a phone screen and call it done. In a real onsite, this question runs 50 to 60 minutes, and the interviewer is using it to probe at least four distinct skills: capacity reasoning, ID generation under distributed constraints, caching strategy, and your awareness of failure modes. Miss two of the four and you fail the round, regardless of how clean your boxes-and-arrows came out.

This walkthrough is the senior version. If you are prepping for L4 / mid-level the bar is lower — you can stop after Step 5. For L5 / senior and L6 / staff, the deep dives are where the round is won or lost.

The Question

“Design a URL shortener service like bit.ly. The service takes a long URL and returns a shorter alias that, when accessed, redirects to the original.”

This question turns up in essentially every system design loop — Amazon, Google, Twitter / X, Reddit, Stripe, Pinterest, and most Series B+ startups doing senior-and-up hires. It is popular because it is a bounded problem with multiple defensible architectures, which makes it a good lens on how you think rather than what you have memorized.

Step 1 — Clarify Before You Draw

Three questions before you draw a single box. Ask these out loud, even if you think you can guess the answer. Spending ninety seconds here is what produces the senior signal.

1. Read-to-write ratio? The almost-universal answer is somewhere between 100:1 and 1000:1. Most short URLs get clicked many more times than they get created. This number drives every caching decision later in the round, so you need it pinned down.

2. Custom short codes allowed, or system-generated only? This question splits the design in half. System-generated only: you can use auto-incrementing IDs and have no collision problem at all. Custom codes allowed: you have a uniqueness check on every write, plus a hot-key problem because everyone wants short, memorable aliases like /sale or /promo.

3. Analytics required? Click counts, geographic data, referrer tracking? If yes, this is no longer a key-value problem. It becomes a key-value problem plus an event pipeline plus an aggregation system. The interviewer is testing whether you spot that the analytics requirement reshapes the architecture.

A senior candidate writes the answers to these three questions on the whiteboard. A junior candidate skips this step, designs for the wrong assumptions, and has to restart twenty minutes in.

Step 2 — Estimate

Pick numbers that justify your architecture. Imprecision is fine; sloppiness is not.

Working assumptions for the rest of this walkthrough:

• 100M new URLs created per month, which gives roughly 40 writes per second on average, with peaks 5 to 10x higher

• 100:1 read-to-write ratio, giving roughly 4,000 reads per second on average, with peaks above 40K

• 5-year retention horizon

• Average record size: 100 bytes for the long URL, 7 bytes for the short code, plus metadata — call it 500 bytes per record

Storage: 100M × 12 × 5 = 6 billion URLs over five years. At 500 bytes per record that is 3 TB. This fits comfortably on a single sharded relational database. You do not need anything exotic.

Bandwidth: 4,000 reads per second × 500 bytes is about 2 MB/s of read traffic. Trivial.

The estimation is not decoration. You will reference these numbers four more times before the round ends — when you justify caching, when you justify sharding, when the interviewer asks “what if we 100x’d the traffic?” Every later trade-off comes back to these inputs.

Get Access to GitHub Repo

Read more

“Didn’t demonstrate sufficient depth.” “Wanted to see stronger technical judgment.” “Good fundamentals but the design wasn’t production-ready.”

None of these tell you what to fix. They’re descriptions of an outcome, not a diagnosis.

After building prep material for engineers targeting L4–L7 at FAANG-tier companies, I’ve spent a lot of time understanding what interviewers actually score — not what they say they score, not what the official rubric says, but what the scorecard entries look like in practice.

Here’s what I’ve found.

The scoring dimensions most engineers don’t know about

The system design interview at most major tech companies is scored on 5–8 explicit dimensions. Two of them, almost everyone knows about:

Technical correctness — did the candidate’s design actually solve the stated problem? Could it work in production?

Depth — did the candidate go beyond the surface answer on at least one component?

The dimensions that separate candidates who barely pass from candidates who get “Strong Hire” are the ones most prep resources ignore:

Subscribe for Question Walkthrough

Problem scoping

The interviewer is watching whether you negotiate the scope of the problem before you start designing. Not ask questions — negotiate scope.

There’s a difference between “what’s the expected scale?” (a question) and “I’m going to focus on the timeline and the fan-out architecture, acknowledge that notifications and search exist, and go deep on the hardest part — does that work for you?” (a negotiation).

Candidates who score well on this dimension don’t try to design everything. They explicitly choose what they’re designing and why, and they do this in the first 3–5 minutes.

Candidates who score poorly try to design everything and end up designing nothing deeply. The 50-minute interview is not enough time to produce depth across a system with the surface area of Twitter. Everyone who attempts it runs out of time before the interesting parts.

Communication clarity

This dimension is scored throughout the round, not at any specific moment. The question: can the interviewer follow your reasoning in real time?

The failure mode is surprisingly common among technically strong candidates: they know what they’re building, but they don’t say it out loud. They draw boxes on the whiteboard and connect them with arrows, and the interviewer has to ask “why did you connect those two boxes?” to understand the design decision.

The fix is specific: every decision should be stated before it’s drawn. Not “here’s a Redis cache” while drawing — “I’m going to put a Redis cache in front of Postgres here because the read:write ratio is 100:1 and the hot read pattern is point lookups by user_id, which Redis handles well at sub-millisecond latency. So here’s the cache.” The decision, then the reasoning, then the diagram.

This sounds slow. It’s actually faster, because the interviewer is never confused about what you’re doing or why. Confusion is the time-killer, not explanation.

Operational maturity

This is the dimension that most separates L5 from L6 scorecards.

An answer that lacks operational maturity designs a system that works on the happy path. Everything goes right. The database responds. The messages are delivered. The cache is warm.

An answer with operational maturity designs a system and then asks: what happens when it breaks?

“The failure mode here is the thundering herd when the Redis node recovers. Without jitter on the retry logic, every request that failed during the outage retries simultaneously the moment Redis comes back. I’d add exponential backoff with ±20% jitter to spread the retry load.”

“I’m targeting p99 < 100ms for the feed read. The leading indicator I’d alert on is cache hit ratio dropping below 90% — that tells me Postgres load is about to spike before users start feeling degraded latency.”

These additions take 30 seconds to say. They produce a measurable difference in how the round is scored.

Level calibration

Interviewers are calibrating your answer against the level you’re being hired for. A brilliant answer that’s calibrated for L4 will not earn a Strong Hire at L6. An adequate answer calibrated correctly for L5 can earn a Hire at L5.

This is worth saying explicitly: you don’t need to demonstrate the maximum possible depth. You need to demonstrate the right depth for your level.

At L4, the bar is: run the framework correctly. Estimate. Design the read and write paths. Mention at least one deep dive.

At L5, the bar is: defend your decisions under probing. Name failure modes. Cover the hard part of the question — the thing that makes this question different from the trivial version.

At L6, the bar is: SLOs with monitoring signals. Cross-system trade-offs. Operational layer. The three things above, plus the “what would tell me this design is failing” for each major component.

Knowing your level and calibrating your answer to it is itself a scored dimension.

The one thing most guides don’t tell you

The design round is not a knowledge test. It’s a judgment test.

Two candidates can produce completely different architectures for the same question and both get Strong Hire. Two candidates can produce very similar architectures and one gets Strong Hire while the other gets No Hire. The architecture is the medium. The judgment — in how you scope, how you communicate, how you reason under pressure, how you handle failure cases — is what’s being evaluated.

This changes how you should prepare.

Memorizing architectures is necessary. It’s not sufficient. The prep that moves the needle is timed practice under interview conditions, with feedback specifically on the four dimensions above — not just on whether your architecture was technically correct.

Every Tuesday, this newsletter publishes one full named-question walkthrough: the exact answer that would earn a Hire signal at your target level, plus the follow-up probes interviewers actually use, plus the common mistakes that fail the round. It covers what the architecture is, why each decision was made, and what the interviewer is specifically looking for.

The first ten questions are published.

https://systemdr.systemdrd.com/subscribe

The free archive has a question bank, the six-step framework cheatsheet, and the estimation numbers reference. All three are downloadable without a subscription.

— Sumedh