System Design Interview Framework & Capacity Estimation

A system design interview is not a test of whether you have memorised the architecture of Twitter. It is a 45-minute simulation of the first design meeting for a new project: an ambiguous prompt, a whiteboard, and a senior engineer watching how you turn ambiguity into a defensible plan. Candidates who fail usually know the building blocks — load balancers, caches, queues — but produce a design that is unmotivated (why is that cache there?), unsized (how big is it?), or unexamined (what happens when it fails?).

This subject gives you the operating procedure. It is the entry point of the System Design Interview track: the individual components (load balancing, caching, replication and sharding, message queues, consensus, and so on) each get their own subject later. Here you learn the framework that strings them together, the numbers you must be able to recall without thinking, and the estimation arithmetic that turns "a lot of users" into "roughly 7,000 writes per second and 55 PB of storage over five years".

Read it once, then rehearse it out loud against the ten prompts at the end. The framework only helps if it is automatic under time pressure.

What Interviewers Actually Evaluate

Most interview rubrics at large companies score four things. None of them is "knew the right answer".

The unstated fifth dimension is calibration to scale. A design for 1,000 users and a design for 100 million users should look different, and the interviewer wants to see you notice which one you are in. That is what capacity estimation is for.

Seniority changes the bar, not the format. A mid-level candidate is expected to produce a coherent design and justify it; a senior candidate is expected to drive the conversation, surface the hard problem unprompted, and reason about failure and evolution.

The Four-Step Framework (45-Minute Time Boxes)

 0        5        10       15       20       25       30       35       40   45
 |--------|--------|--------|--------|--------|--------|--------|--------|----|
 | 1. Requirements  | 2. Est.| 3. High-level design      | 4. Deep dives   |Wrap|
 |   (~5-8 min)     |(~3-5)  |   (~10-15 min)            |   (~15 min)     |(~3)|

Adjust proportionally for a 60-minute slot. Announce the plan at the start: "I'd like to spend a few minutes on requirements and scale, sketch a high-level design, then go deep on whichever parts you find most interesting." Interviewers almost always agree, and now they know where you are.

Step 1 — Clarify requirements (5–8 min)

Split them explicitly into two lists.

Functional requirements — what the system does. Pick the 3–5 core use cases and say what you are not doing.

• "Users can post a message of up to 280 characters; users can follow others; users see a reverse-chronological feed of people they follow."
• Out of scope: "search, ads, direct messages, analytics" — say it out loud and write it in the corner of the board. Interviewers reward candidates who bound the problem.

Non-functional requirements — how well it does it. Walk this list every time:

Also settle who the users are (consumers vs internal), read-heavy or write-heavy, and any hard constraints ("must be global", "mobile clients on flaky networks").

Step 2 — Back-of-envelope estimation (3–5 min)

Compute QPS (average and peak), storage growth, bandwidth, and memory for a cache. Round aggressively; the goal is orders of magnitude. The full method and worked examples are below.

Step 3 — High-level design (10–15 min)

Build in this order, because each layer constrains the next:

1. API — the 3–5 endpoints matching the functional requirements.
2. Data model — the core entities, their keys, and the access patterns.
3. Core components — client → load balancer → stateless services → cache → database, plus queues/workers if there is asynchronous work.
4. Data flow — walk one write path and one read path end to end on the diagram.

Keep it boring. A high-level design that looks like every other web system is a good sign; the interesting decisions come in the deep dives.

Step 4 — Deep dives and bottlenecks (15 min)

Ask: "Which part would you like to dig into?" If they leave it to you, choose the component that your estimates showed to be under the most pressure — the write path at 7k QPS with fan-out, the 350k read QPS cache tier, the 55 PB media store. For each deep dive cover: the specific problem, two candidate approaches, the trade-off, and the failure mode.

Wrap-up (2–3 min)

Summarise the trade-offs you made, name the top failure modes and how the design handles them, and list what you would do next with more time (multi-region, analytics pipeline, abuse controls). Ending on "future work" signals that you know the design is a snapshot, not a monument.

The Numbers Every Candidate Must Know

You cannot estimate without reference values. Learn these to the nearest order of magnitude; nobody will fault you for saying "about 100 microseconds" when the true figure is 150.

Powers of two and data sizes

Field sizes to reuse: ASCII char 1 B (UTF-8 up to 4 B); int 4 B; bigint/timestamp 8 B; UUID 16 B; a URL ≈ 100 B; a typical database row with a dozen columns ≈ 100 B–1 KB; a minute of 1080p video at streaming bitrates ≈ 50 MB.

Time

The single most useful shortcut: 1 million requests per day ≈ 12 requests per second (because 10^6 / 86{,}400 \approx 11.6). So 300 million per day ≈ 3,500/s.

Latency numbers (orders of magnitude)

What to take from the table, in interview form: memory is roughly a thousand times faster than SSD, SSD is roughly a hundred times faster than spinning disk, a same-DC network hop costs about a disk read from RAM's perspective, and a cross-region hop costs about a hundred same-DC hops. That is why caches live in RAM, why sequential I/O beats random I/O, why chatty cross-service calls kill p99, and why global products need regional replicas.

Availability: nines → downtime

Two facts to state: (1) availability of serial dependencies multiplies — two 99.9% services in a request path give 0.999^2 \approx 99.8\%; (2) each extra nine costs roughly an order of magnitude more engineering (multi-AZ → multi-region → automated failover with no human in the loop).

Throughput a single node handles (orders of magnitude)

These are for guessing how many nodes, not for tuning. If your estimate says 350k cache reads/s, that is "a handful of Redis nodes", not one; if it says 7k database writes/s with fan-out, that is "at or past the comfort zone of a single primary — talk about sharding".

Capacity Estimation Method

Do the arithmetic on the board, in this order, saying the assumptions out loud so the interviewer can correct any of them:

1. Users — DAU (assume ~50% of MAU if only MAU is given).
2. Traffic — actions per user per day → requests/day → ÷ 86,400 → average QPS; peak ≈ 2–3× average.
3. Read/write ratio — split QPS into reads and writes.
4. Storage — bytes per write × writes/day → per day → × 365 × retention years.
5. Bandwidth — bytes/day ÷ 86,400 for ingress and egress separately.
6. Cache — the 80/20 rule: 20% of the day's content serves 80% of reads, so cache ≈ 20% of daily data volume (or of the working set).
7. Servers — QPS ÷ per-node capacity, then add headroom for peaks and failures (N+1 or N+2).

Round every intermediate result to one significant figure. Precision is fake here; the interviewer wants the shape of the numbers.

Worked example 1 — a Twitter-like service

Assumptions (stated aloud): 300 M MAU, 50% active daily → 150 M DAU. Each user posts 2 tweets/day and reads their timeline about 10 times/day, viewing ~20 tweets each time. 10% of tweets carry a 1 MB image; a tweet's text + metadata ≈ 500 B. Retain everything for 5 years.

Write QPS

Read QPS

Read:write ratio ≈ 100:1 → this is a read-heavy system; caching and precomputed timelines will dominate the design.

Storage

• Text/metadata: 300\text{M} \times 500\ \text{B} = 150\ \text{GB/day} → \times 365 \times 5 \approx 274\ \text{TB} over 5 years.
• Media: 30\text{M} \times 1\ \text{MB} = 30\ \text{TB/day} → \times 365 \times 5 \approx 55\ \text{PB} over 5 years.

Conclusion to say out loud: metadata fits in a sharded relational or wide-column store; media must go to object storage behind a CDN — it is 200× the metadata volume.

Bandwidth

• Ingress ≈ 30\ \text{TB/day} / 86{,}400 \approx 350\ \text{MB/s} (dominated by media).
• Egress: 30 B reads/day × 500 B ≈ 15 TB/day of text ≈ 175 MB/s, plus a large multiple for media served from the CDN.

Cache size (80/20 rule) — cache 20% of the tweets generated per day: 0.2 \times 150\ \text{GB} = 30\ \text{GB}. That fits in RAM on a small cluster; the constraint on the cache tier is not memory but the 350k reads/s, which is several Redis nodes' worth of throughput plus replicas.

Servers — 350k reads/s at ~5k QPS per app server → ~70 app servers, round to ~100 with headroom. Writes are 3.5–7k/s, but if each tweet fans out to an average of 200 followers' timelines, that becomes ~700k–1.4M timeline-cache writes/s — this is the number that reveals the hard part of the design (fan-out on write vs fan-out on read; the Design News Feed subject covers it).

Worked example 2 — a video-sharing service

Assumptions: 100 M DAU; 5% upload one video per day; average raw upload 300 MB; each user watches 5 videos/day, average 10 minutes at 5 Mbps.

Uploads

• Ingress bandwidth ≈ 1.5\ \text{PB} / 86{,}400 \approx 17\ \text{GB/s}.
• Storage/year ≈ 1.5\ \text{PB} \times 365 \approx 550\ \text{PB} raw, before transcoded variants (multiply by ~1.5–2 for the extra renditions, minus compression).

Views

Bytes per view: 5\ \text{Mbps} \times 600\ \text{s} = 3{,}000\ \text{Mb} \approx 375\ \text{MB}. Egress \approx 500\text{M} \times 375\ \text{MB} \approx 190\ \text{PB/day} \approx 2.2\ \text{TB/s}.

Conclusion: the metadata traffic (15k QPS at peak) is easy — a dozen app servers plus a cache. The design is dominated by bytes on the wire, so the interesting decisions are CDN placement, adaptive bitrate, transcoding pipeline as an asynchronous queue-driven job (58 uploads/s × minutes of CPU each = a worker fleet in the hundreds), and cold-storage tiering for the long tail of videos nobody watches. The estimate told you where to spend the deep-dive time.

Sketching the API, the Data Model, and the Diagram

API sketch

Write endpoints as VERB /path → response, with the key parameters. Keep them resource-oriented; the API Design & Communication subject covers REST vs gRPC vs GraphQL, pagination and versioning in depth.

POST   /v1/tweets                 body: {text, media_ids[]}        → 201 {tweet_id, created_at}
GET    /v1/tweets/{id}                                            → 200 {tweet}
GET    /v1/users/{id}/timeline    ?cursor=&limit=20                → 200 {tweets[], next_cursor}
POST   /v1/users/{id}/follow      body: {target_user_id}          → 204

Two things to say while writing it:

• Idempotency: any write a client might retry (payments, posts, uploads) accepts an Idempotency-Key header or a client-generated ID so a retried request does not create a duplicate. Reliability & Observability Patterns goes deeper on retries; here you just need to show you thought about it.
• Pagination: cursor-based (next_cursor), not offset, for feeds that change under the reader.

Data model sketch

Name the entities, their primary keys, and — critically — the access patterns, because access patterns decide SQL vs NoSQL and the shard key (the SQL vs NoSQL Data Modeling and Database Replication & Sharding subjects go deep on that).

users     (user_id PK, handle, created_at, ...)
tweets    (tweet_id PK, user_id, text, media_url, created_at)   -- index (user_id, created_at DESC)
follows   (follower_id, followee_id)  PK(follower_id, followee_id), index on followee_id
timeline  cache: user_id -> [tweet_id, ...] (most recent ~800)

Say what each table is keyed for: "tweets by author in reverse chronological order", "who does X follow", "who follows X".

Drawing conventions

Draw left-to-right in the direction of a request. Label arrows with the protocol or the operation, and put the number you estimated next to any hot edge.

                         350k reads/s
 [Clients] ──HTTPS──> [CDN] ──> [Load Balancer] ──> [Timeline Service ×N] ──> [Timeline Cache (Redis)]
                                    │                       │  miss                     ▲
                                    │                       ▼                           │ fan-out writes
                                    │               [Tweets DB (sharded)]      [Fan-out Workers] <── [Queue]
                                    │                       ▲                                           ▲
                                    └──> [Tweet Service] ───┘ 3.5k–7k writes/s ────────────────────────┘
                                             │
                                             └──> [Object Store] <── media uploads (350 MB/s)

Conventions that keep a whiteboard readable: boxes for services and stores, cylinders (or [DB]) for durable storage, a dashed box or ×N for horizontally scaled tiers, arrows for the request direction with a label, and a small number wherever your estimates apply. Redraw rather than patch a messy diagram — it takes 30 seconds and the interviewer will remember the clean version.

How to Talk About Trade-offs

Every non-trivial choice should be spoken as a sentence with four parts — the choice, the alternative, the requirement that decides it, and the cost you accept:

"I'd choose X over Y here because we need requirement Z (which we established/estimated earlier); the cost is W, which is acceptable because … / which we mitigate by …."

Examples:

• "I'd choose fan-out on write over fan-out on read because reads outnumber writes 100:1 and we want timeline p99 under 100 ms; the cost is amplified writes for users with millions of followers, which we mitigate by handling celebrities with fan-out on read."
• "I'd choose asynchronous replication over synchronous because the availability target is 99.99% and cross-region round trips are ~150 ms; the cost is a small window of possible data loss on primary failure, which is acceptable for likes but not for payments."

The template forces you to tie choices back to requirements, which is precisely what the rubric rewards. It also gives the interviewer a hook: they can change requirement Z and watch you re-decide, which is a strong senior signal.

Common Mistakes / Interview Traps

• Jumping to technology names. "We'll use Kafka, Cassandra and Elasticsearch" before any requirement is stated reads as pattern-matching, not design. Name the role first (a durable log, a wide-column store, an inverted index), then a product if asked.
• No numbers. A design with no QPS, no storage figure and no latency budget cannot be evaluated. Even rough estimates change what "correct" means.
• Ignoring the interviewer. Hints ("what if a user has 10 million followers?") are the interviewer steering you toward the part they grade. Take them immediately.
• Over-engineering. Multi-region active-active with CRDTs for a 10k-user internal tool is a negative signal. Match the design to the scale you estimated and say when you would add the next layer.
• Under-engineering the hard part. The mirror image: spending 15 minutes on the login flow and 2 minutes on the fan-out problem.
• Not covering failure. Every component you draw will fail. Say what happens when the cache is cold, the primary dies, the queue backs up, or a region is unreachable.
• Treating consistency as free. "It's strongly consistent" must come with the cost (latency, availability during partitions). The CAP Theorem subject gives you the vocabulary.
• Silent estimation. Doing arithmetic in your head and announcing a result gives the interviewer nothing to check. Write the multiplication on the board.
• Never bounding scope. Without an explicit out-of-scope list, every question becomes fair game and you run out of time.
• Ending without a summary. The last two minutes are where the interviewer forms the write-up; give them the trade-offs and next steps in a tidy list.

Checklist to Memorise

Walk this list mentally at each phase; it takes ten seconds and prevents most of the mistakes above.

Requirements

• [ ] 3–5 functional use cases stated; out-of-scope list written down
• [ ] Scale (DAU, QPS, data), latency target, consistency, availability, durability, cost asked about
• [ ] Read-heavy or write-heavy decided

Estimation

• [ ] Average and peak QPS for reads and writes
• [ ] Storage per day and over the retention period
• [ ] Ingress/egress bandwidth
• [ ] Cache size (80/20) and rough server counts

High-level design

• [ ] API endpoints with idempotency and pagination considered
• [ ] Data model with keys and access patterns
• [ ] Diagram: client → edge/LB → stateless services → cache → storage (+ queue/workers)
• [ ] One write path and one read path walked end to end

Deep dives

• [ ] The bottleneck the estimates exposed, with two options and a trade-off sentence
• [ ] Failure modes: cache cold/miss storm, DB primary loss, queue backlog, hot key/partition, region outage
• [ ] Scaling path: what breaks first at 10× load

Wrap-up

• [ ] Trade-offs recap, top failure modes, future work

Ten Classic Prompts, One-Line Framing Each

For each, the same four steps apply; only the deep dive changes.

Key Takeaways

• Interviewers grade structure, trade-off reasoning, communication, and depth on the hard part — not memorised architectures.
• Run the four steps with time boxes: requirements (incl. out-of-scope) → estimation → high-level design (API → data model → components → data flow) → deep dives, then a two-minute wrap-up.
• Memorise the reference numbers: 1 M/day ≈ 12/s, RAM ≈ 100 ns, SSD read ≈ 100 µs, same-DC round trip ≈ 0.5 ms, cross-region ≈ 150 ms, 99.9% ≈ 8.8 h/year down, 99.99% ≈ 53 min/year, single DB primary ≈ 10^3–10^4 writes/s, Redis ≈ 10^5 ops/s.
• Estimation is a fixed procedure: DAU → actions/day → QPS (avg, then ×2–3 peak) → read/write split → storage → bandwidth → cache via 80/20 → servers with headroom. Say the assumptions and write the arithmetic.
• The estimates choose the deep dive: the number that looks scary (fan-out writes, media bytes, cache QPS) is where the design earns its grade.
• State every choice as "X over Y because Z; the cost is W, mitigated by …".
• Always cover failure: cold cache, dead primary, backed-up queue, hot key, lost region.
• The components themselves — load balancing, caching strategies, consistent hashing, replication and sharding, SQL vs NoSQL modeling, indexing, queues, rate limiting, API design, distributed transactions and consensus, reliability patterns — are each taught in their own subject later in this track; this framework is how you assemble them.