System Design Interviews

System Design Interview Framework

The interviewer says: "Design a chat product like WhatsApp." You have about 45 minutes. They are not waiting for a memorized diagram. They want to see whether you clarify scope, use numbers, make trade-offs, and handle failure like a teammate.

This page pairs with How to Approach System Design: there you practice pacing and a full worked example; here we unpack what interviewers write on scorecards and how lines up with those signals.

Leave evidence for

Requirements

Users, scope, latency, freshness.

Estimation

, storage, peak multiplier.

Architecture

Read, write, and async paths.

Depth + ops

, failures, metrics.

What actually happens in a strong round

You start by narrowing and . For chat, that might mean one-to-one messaging first, group chat later, and an explicit freshness or delivery promise.

Rough and storage math then force architecture choices: when cache helps, when partitions appear, when async delivery is acceptable. You draw the happy path, then go unusually deep on one or two instead of listing every trendy store.

Near the end, you cover retries with , failure modes, and signals such as latency or queue age. That is the evidence an interviewer can write on a scorecard.

Try it: score your interview evidence

Interviewers grade buckets, not diagram beauty. Rate what you would leave on the whiteboard for requirements, numbers, architecture, depth, failures, and communication.

Total score: 6 / 12
Suggested focus: Rebuild fundamentals before timed mocks

Requirements

Score 1

Functional vs non-functional scope is explicit.

Estimation

Score 1

QPS, storage, and peak factor tie to decisions.

Architecture

Score 1

Read, write, and async paths are separable.

Depth

Score 1

One or two bottlenecks explored with mechanisms.

Failures

Score 1

Retries, idempotency, degradation, and metrics named.

Communication

Score 1

Assumptions stated; interviewer can follow the narrative.

Rebuild fundamentals before timed mocks

Practice clarifying scope and drawing one path out loud. Your scorecard gaps map to Requirements, Estimation, and Architecture first.

Score each scorecard bucket from 0 (missing) to 2 (would leave clear whiteboard evidence). The total suggests what to emphasize in your next mock.

Align with RESHADED without reciting it. If Estimation and Architecture score low, fix pacing before adding more case studies. If Depth and Failures score low, pick one mock and stay on the bottleneck until retries and metrics appear.

With that arc in mind, use the next card as a quiet filter for what to emphasize on the whiteboard.

How to choose what evidence to leave

1. Clarify before you draw. Scope control prevents over-building the wrong system: start with and .

2. Let numbers drive components. Caches, queues, and shards should follow estimates, not habit (formulas live in Numbers to know).

3. Go deep twice, not shallow ten times. Two with failure handling beat a buzzword parade.

Simple rule of thumb

Treat as a silent checklist, not a script you recite. If every letter leaves one piece of evidence on the whiteboard, the round usually scores well.

Three sentences to remember

Clarify scope before drawing components so you solve the right problem.
Use rough numbers to justify caches, queues, and partitions under load.
Go deep on two bottlenecks rather than shallow on ten technologies.

Next comes the scorecard view: what interviewers listen for, what they can write down, and which production moves make the answer sound operable.

Scorecard, evidence, and operable signals

Leave evidence that a reviewer can evaluate. For a chat system, a useful requirement is “a message acknowledged as sent remains stored if a gateway restarts.” A useful design explanation then identifies the message store, the commit boundary, and the acknowledgment sent to the client. A useful failure answer explains how a reconnecting client retrieves messages after its last known cursor. These three statements connect product scope, architecture, and reliability.

There is rarely one correct architecture. Rubrics reward structured exploration, sound component choices, quantitative reasoning, credible trade-offs, and depth on critical paths, communicated clearly under time pressure. A strong answer touches each rubric signal at least once without announcing the rubric.

Scorecard to answer map

Problem statement

Requirements evidence

Estimation evidence

Architecture evidence

Deep dive evidence

Trade-off evidence

Failure and ops evidence

Hire signal

What interviewers expect

Concrete evidence: assumptions, rough numbers, justified components, clear failure handling, and trade-offs tied to requirements.

Common follow-up pattern

"What changes at 10x?", "What if this dependency fails?", "Why not the alternative?", and "How would you monitor this?"

Evidence log: what the interviewer can write down

Think of the interview as leaving proof after each phase. Strong answers make the evidence easy to capture.

Requirements: Stated users, core scope, latency, availability, and freshness assumptions for the product.
Estimation: Calculated , storage, bandwidth, and peak multiplier that justify scale choices.
Architecture: Drew clients, API (Application Programming Interface), services, cache, database, queue, and workers.
Deep dive: Explained the riskiest component with data model, scale, and failure behavior under load.
Trade-offs: Compared at least two options and named the accepted downside for this product.
Operations: Named metrics, alarms, fallback behavior, and rollout or recovery path for incidents.

Production-ready case-study signals

These moves turn a whiteboard design into an answer that sounds operable: start with the invariant, let numbers force decisions, trace every path, then show how the system is launched and maintained.

Invariant first

Name the promise the system must never violate before picking stores or queues.

Example: no double booking, no lost acknowledged writes, no duplicate charge, no private feed item returned.

Numbers to decisions

Convert scale math into architecture choices instead of leaving estimates as trivia.

Example: 100K read QPS justifies cache and replicas; 10K writes/sec justifies partitioned ingestion and backpressure.

Four path tracing

Draw read, write, async, and failure paths separately so critical work and fallback behavior are clear.

Example: checkout write path is authoritative; notification and analytics paths are async and replayable.

Operations and testing

Explain how the design is measured, secured, degraded, tested, rolled out, repaired, and evolved at 10x.

Example: p99 and queue-age alerts, canary rollout, load/failure tests, idempotent backfills, and a rollback runbook.

The ladder below shows how the same phase sounds weak, acceptable, or strong, so you can self-check phrasing without new facts.

Answer quality ladder

Requirements

Weak: I will design everything.
Acceptable: I will support posting and reading messages.
Strong: I will scope to posting, reading, and follow relationships; keep payments and moderation out unless needed.

Estimation

Weak: It should scale a lot.
Acceptable: Assume 10M daily users.
Strong: 10M daily users times 5 reads gives 50M reads/day, about 580 average QPS and 3K peak QPS with a 5x multiplier.

Trade-offs

Weak: Use cache because it is fast.
Acceptable: Cache improves reads but can be stale.
Strong: I will use cache-aside with 60 second TTL (Time To Live); we gain p95 latency but accept short stale reads and monitor hit ratio.

Failure handling

Weak: Add more servers.
Acceptable: If database fails, use replicas.
Strong: If primary database is slow, serve cached reads where freshness allows, shed expensive requests, and page on p99 database latency plus replication lag.

Scored weak example: 2 / 10

"I would use microservices, Redis, Kafka, and sharding so it scales globally."

No clarified scope before naming stores or services.
No estimates or named bottleneck driving the stack.
No reason for the chosen components under load.
No failure mode or explicit trade-off stated.

Scored strong example: 8.5 / 10

"I will scope to posting and feed reads, assume eventual consistency for likes, estimate read QPS first, then use cache plus fan-out strategy because the read path dominates. I will monitor feed p99, cache hit ratio, and queue age."

Clear scope and explicit assumptions before the diagram.
Numbers lead to the design choice on the read path.
Trade-off is named instead of hidden behind tools.
Ends with measurable operations signals for health.

When you need a letter checklist and a rough clock, the next card packs with a 45-minute pacing sketch.

The RESHADED method and 45-minute timeline

Treat the framework as a way to check completeness, not a script that forces the same components into every problem. An API choice may expose a data-model problem; a storage estimate may reveal that a proposed retention policy is unaffordable. Move back to the affected assumption and update it aloud. This is progress because the design is becoming more internally consistent.

RESHADED: 8 steps to structure any system design

Letters do not need to be strictly linear, you might bounce between high-level design and API tweaks, but every letter should appear somewhere in a strong round.

R	Requirements	Clarify functional & non-functional requirements
E	Estimation	Back-of-envelope math (QPS, storage, bandwidth)
S	Storage Schema	Data model, database choice, schema design
H	High-Level Design	Components, APIs, data flow diagram
A	API Design	Endpoints, request/response formats, pagination
D	Detailed Design	Deep dive into 2-3 critical components
E	Evaluation	Trade-offs, bottlenecks, failure modes
D	Distinct Features	Unique aspects (real-time, geo, ML, etc.)

5 min

Requirements (CRITICAL)

10 min

High-Level Design

15 min

Detailed Design

10 min

Trade-offs

The 45-minute timeline

Minutes 0–5: Requirements

ASK (don't assume)

plaintext

"Who are the users?" (consumers, businesses, internal)
"What's the scale?" (DAU, peak QPS)
"What are the core features?" (list 3-5)
"What are the constraints?" (latency, consistency)

EXAMPLE (Design social feed):
Functional: Post updates, follow users, news feed
Non-functional: 500M DAU, 99.99% availability
Constraints: Feed latency <200ms, eventual consistency OK

Minutes 5–10: Estimation

QUICK MATH (social feed example):

~50K/sec peak reads so caches and replicas earn their keep.
~10K/sec peak writes so ingestion and queues need planning.
~27TB/yr text storage so retention and partitioning matter early.
~12TB/day media storage so blob stores and CDNs enter the design.

These numbers drive design decisions (see also Numbers to know).

Minutes 10–25: High-Level Design

Draw the architecture: clients, load balancers, API servers, databases, caches, message queues, CDN. Define APIs for each core feature. Explain data flow for the primary use cases. This is your skeleton: interviewers check whether your components are reasonable before going deeper.

Minutes 25–40: Deep Dive

Pick 2–3 components that are most interesting or challenging. For a social feed: News Feed generation (fan-out), post storage (sharding strategy), high-fanout user problem (hot keys). Show depth: discuss algorithms, data structures, failure modes, and scaling strategies.

Level bands differ by company; read expectations as signals. The four rubric flags below match the scorecard map so you can listen for them live.

Levels and interview rubric

What interviewers score by level

Level	Expectation	Signal
Junior (L3-L4)	Working high-level design, reasonable component choices, identifies obvious bottlenecks	"Can they build something?"
Senior (L5 / E5 / SDE3)	Detailed component design, quantitative reasoning, discusses caching/sharding/replication; drives most of the session	"Can they own a service end-to-end?"
Staff (L6 / E6)	Anticipates failure modes and ops concerns; compares migrations vs greenfield; balances depth with cross-team constraints	"Can they design across team boundaries?"
Staff+ (L7+ / E7+)	Surfaces hidden requirements, ties designs to cost/compliance/multi-region evolution; teaches peers	"Can they set technical direction?"

Rubric signals

Problem exploration signal

Do you ask the right clarifying questions? Do you define scope before jumping to solutions? Do you identify both functional and non-functional requirements?

Red flag: Starting to draw architecture before understanding requirements. Green flag: “Before I design, let me clarify what consistency guarantees we need.”

High-level design signal

Is the architecture sound? Are the right components present? Does data flow make sense? Are APIs well-defined?

Red flag: Missing a justified capacity plan for the dominant workload. Green flag: Clean diagram with clear data flow and justified technology choices.

Detailed design signal

Can you go deep on specific components? Do you discuss data structures, algorithms, and implementation details? Do you handle edge cases?

Red flag: Staying surface-level on everything. Green flag: “For the fan-out service, I'd use a hybrid approach: fan-out on write for users with fewer than 10K followers, fan-out on read for celebrities.”

Trade-offs & evaluation signal

Do you proactively discuss alternatives? Do you identify bottlenecks and failure modes? Can you explain why you chose one approach over another?

Red flag: Presenting one solution as obviously correct. Green flag: “This access pattern is mostly writes and key-based reads. I would compare a partitioned relational store with a wide-column store, then check the required transaction boundaries and consistency guarantees before choosing.”

When the conversation gets sticky, use these short verbal moves instead of inventing new architecture mid-sentence.

Interview-grade response blocks

Use these as short verbal moves. They show the interviewer you can structure ambiguity, communicate trade-offs, and recover without bluffing.

What to say

Scope the core flow first, then add scale and failure handling later.
This requirement makes the write path more important than reads.
The main bottleneck is likely the fanout queue, not APIs.
I accept stale reads here; I would monitor cache hit ratio.

What not to overdo

Do not enumerate every feature before picking the core flow.
Do not add sharding, queues, and caches without supporting numbers.
Do not deep dive into syntax or framework details unless asked.
Do not treat , multi-region, and strong consistency as free.

Common follow-ups

Same pattern as the scorecard card: 10x traffic, dependency failure, hot keys or celebrity users, and unhealthy metrics.

How to recover if stuck

Return to one record and trace its lifecycle. For a message, ask who creates its identifier, who is permitted to send it, where it is stored, when the sender sees success, and how the recipient resumes after disconnecting. Each answer exposes the next necessary decision. If a specific database feature is unfamiliar, state the guarantee you need and compare designs under that assumption instead of guessing what the product provides.

Restate the invariant: we cannot lose acknowledged writes under retries.
Trace one request end-to-end and name the first uncertain step.
Offer two options and ask which direction to explore next.
State uncertainty honestly, then reason from stated constraints.

Estimation is how you turn daily volume into architecture decisions; keep the formulas here and cross-ref them from earlier sections.

Numbers to know

A number only helps if its unit and boundary are clear. “5,000 writes per second” might count original posts, fanout messages, database rows, or replicated log writes. In the feed example below, 400 million daily timeline writes are derived work, in addition to storing the original posts. Replication and indexes can multiply physical work further. Label the arrow being counted and state whether a peak factor has already been applied.

Capacity math is scoring evidence: a good estimate shows why you added a cache, queue, partition, or CDN rather than naming tools from habit.

Metric	Formula	Why it matters
	daily actions / 86,400 × peak multiplier	Sizes APIs, DB writes, queues, and rate limits
Storage	records/day × bytes/record × retention	Decides partitioning, blob storage, and backup strategy
Bandwidth	response bytes × read QPS	Justifies CDN, compression, and pagination
Fanout	writes/sec × average recipients	Reveals queue depth, hot keys, and push vs pull choices
Cache hit ratio	hits / total reads	Turns cache talk into source-of-truth load math
p95 latency	budget per hop, not average only	Prevents slow tails hidden by good averages

Worked example: 5M daily posts, average 400 followers, 20% fanout-on-write means 5M × 400 × 20% ≈ 400M timeline writes/day, or ~4.6K average writes/sec before peak multiplier. That estimate tells you the fanout queue and cache writes deserve the deep dive.

Close the page with practice habits: how you talk, what you draw, mistakes to avoid, and the core skill to rehearse.

Practice wrap-up: conversation, diagrams, mistakes

How to drive the conversation

1. SIGNPOST

“I'll start with requirements, then estimation, then high-level design, then deep dive into 2 areas.”

2. CHECK IN

“I've covered the high-level design. Should I go deeper into the feed generation, or the storage layer?”

3. THINK ALOUD

“I'm choosing a write-optimized store here because we need high write throughput and can tolerate eventual consistency.”

4. SELF-CRITIQUE

“One concern with this approach is hot partitions. To mitigate that, I'd add a write buffer with consistent hashing.”

5. RECOVER GRACEFULLY

If stuck, say “Let me think about this differently...” and approach from first principles.

PRO TIP: The interviewer is your collaborator, not adversary. When they ask “What about X?” they're guiding you, not trapping you.

Whiteboard and diagramming tips

Layout

Left-to-right flow: Client → load balancer → API → service → database. Leave space to add components. Use rectangles for services, cylinders for databases, clouds for external services. Label every arrow with the protocol or interaction style (HTTP, RPC, queue).

Annotations

Write numbers next to each component. Note cache hit rates. Mark async vs sync connections. Show read vs write paths in different colors. Annotate with latency budgets: “Target: 200ms total = 50ms API + 100ms DB + 50ms network.”

Progressive detail

Start with 5–6 components. Add detail where the interviewer shows interest. Zoom into a component by drawing a separate detailed diagram. Never erase: draw the detailed version nearby and connect it with a dotted line.

Common mistakes

Depth is not the number of algorithms mentioned. Choosing a fanout threshold is only the beginning: explain how follower count translates into write amplification, what occurs when a user crosses the threshold, and how readers avoid missing or duplicating posts during that transition. Use estimates to propose an initial threshold and measurements to tune it. A fixed follower number without these assumptions is not a generally valid design rule.

Mistake	Fix
Diving into code immediately	Start with requirements + estimation
Designing for global scale from day 1	Start simple, explain how to scale
Only one solution, no alternatives	Always discuss 2+ approaches
Ignoring non-functional requirements	Ask about latency, consistency, SLA
Silence for 2+ minutes	Think aloud, narrate your reasoning
Not managing time	Timebox each phase, move on
Naming technologies without reasoning	Explain WHY you chose each component
Ignoring interviewer hints	"Great point, let me address that..."
No numbers anywhere	Estimate QPS, storage, latency (Numbers to know)
Over-engineering for the time limit	Focus depth on 2-3 key components

The core skill

The system design interview is not about memorizing architectures: it's about demonstrating engineering judgment. Practice by designing real systems end-to-end: pick a product you use daily, estimate its scale, design its architecture, then read how similar systems are usually built. Compare your design to theirs. The gap between your design and reality is your learning opportunity. Repeat this with varied workloads and review the reasoning gaps you find; readiness depends on what you can explain and adapt, rather than a fixed case-study count.

Primary sources

Google SRE: Service Level Objectives: quantify success before drawing boxes.
AWS Architecture Center: reference shapes to compare against.
RFC 2119: state invariants with MUST/SHOULD.

Practice and further reading

Use these exercises to connect the lesson to a design decision. State your assumptions, trace what happens to one request, and explain the rule that must remain true even during a failure. That rule is the design's correctness invariant.

Focus for this lesson: Make interview quality observable with a rubric covering clarification, estimates, correctness, APIs/data, failure analysis, trade-offs, and communication.

Explain the decision

What separates a senior answer from a diagram with familiar components?

Read the reasoning

The senior answer quantifies assumptions, names invariants and ownership, analyzes gray failures, and makes rollout and recovery part of the architecture.

Apply it to a production scenario

A candidate has a sound design but never discusses overload or rollback. How should the rubric score it?

Read one approach

Credit the core model but mark production readiness incomplete; overload and safe change are first-class dimensions, not optional polish.

Work through the numbers

Allocate 45 interview minutes across discovery, estimates, core design, deep dive, and recap.

Read the worked calculation

A useful baseline is 5 + 5 + 12 + 18 + 5 minutes, then adapt when the interviewer explicitly asks to deepen an area.

Reason through a failure

What is the invariant for the interview process itself?

Read the recovery reasoning

Every major box must trace back to a requirement or constraint; unexplained infrastructure is a design smell and a communication failure.

Sources and further study

Continue with Distributed Systems Fundamentals.