System Design Interview Framework
Master the system design interview framework: structured approach, common patterns, and evaluation criteria.
What is a System Design Interview Framework?
A system design interview framework is a repeatable way to turn an ambiguous product request into a design that can be checked against real constraints. It starts with what users need, converts those needs into scale and reliability targets, then explains an architecture and its trade-offs.
It matters because a diagram alone cannot show whether a system is appropriate. A strong answer makes every major component earn its place. Invariant: each design decision must trace back to a stated requirement, constraint, or measured risk.
1 First 5-10 minutes
Frame the problem
Name the users, their most important action, what is out of scope, and the business fact that must stay true.
2 Next 5-10 minutes
Quantify pressure
Estimate peak reads, writes, payloads, retained data, and the latency or availability target that constrains the design.
3 Next 10-15 minutes
Draw the smallest path
Trace the request through the source of truth and introduce cache, queue, replica, or worker only for a named reason.
4 Final 10-15 minutes
Test failure and trade-offs
Say what the user sees during dependency failure, what can be stale, how the design is measured, and what you would discuss next.
Start with a Testable Product Contract
Requirements are observable promises to a user or operator. Before choosing storage or services, separate the work into four short lists.
- Functional path: who does what, which read or write is critical, and what a successful result means.
- Quality targets: peak load, p95 latency, availability, freshness, and durability targets.
- Scope boundary: features deferred from this answer, such as recommendations, full-text search, or analytics.
- Invariant: the fact that cannot be violated, such as "a confirmed seat is never sold twice" or "a payment is charged at most once."
An assumption is useful only when it changes the design. State it aloud: "I will assume 99.9% availability and a 200 ms p95 for reads; I will revise the path if the interviewer needs stronger guarantees."
Turn a Brief into Design Pressure
Scale estimates are directional calculations that eliminate unsuitable designs. They do not need false precision. First find average demand, then multiply by a peak factor; calculate retained writes separately from reads.
Make the product brief constrain the design
Choose a product scenario, then change its peak, retention, and user-facing target. The derived pressure shows what to clarify before drawing boxes.
Loading product constraints...
Build the Critical Path Before the Component List
A critical path is the shortest sequence of dependencies that must work for the important user action to complete. Draw it in request order, then explain the owner of each state transition.
Admission
Edge and API
Authenticate, validate, rate-limit, and attach a request or idempotency key. This layer should not quietly decide durable business state.
Commit
Service and source of truth
Apply the invariant in one well-defined place. A transactional store is often the initial source of truth for an order, reservation, or payment state.
Controlled relief
Cache or queue
Cache safe, repeatable reads; use a durable queue after a committed write for slow or retryable side effects. Neither replaces the authoritative record.
Explain each boundary
- Cache boundary: say what can be served stale, how it is invalidated or expires, and the behavior on a cache miss or outage.
- Queue boundary: commit the user-visible state first, then enqueue side effects with an idempotent consumer and retry policy.
- Consistency boundary: identify the read that must observe a completed write versus the view that may converge later.
- Failure boundary: state whether the user is rejected, given a pending result, or served a labeled stale result when a dependency is unavailable.
Practice Defending a Design Under Pressure
Trade-off analysis is the explanation of what a choice protects, what it gives up, and when you would revisit it. Change the design below. The output exposes components that no longer have a requirement, the user-visible path, and the next question worth spending interview time on.
Defend the path when the interviewer changes the constraint
Choose the source of truth, relief boundary, consistency contract, and failure response. The review separates coverage from accumulated design debt.
Loading architecture decisions...
Make Implementation Choices Defensible
An implementation detail is useful in an interview when it demonstrates how the invariant survives retries, concurrency, or failure. For a create operation, an idempotency key lets the server return the first result when a client retries after a timeout.
The handler makes the reservation and its outbox record part of one transaction. A separate worker can publish the outbox record repeatedly because downstream consumers receive a stable event ID. This is safer than charging a user or sending an email before the durable reservation is known to exist.
Close with Operations, Not More Boxes
Operations are the measurements and recovery actions that keep the design truthful after launch. End an interview answer by naming the trigger, signal, and response.
- Measure the user contract: p95/p99 latency, success rate, confirmed-versus-requested actions, and freshness age for asynchronous views.
- Measure the boundary: cache hit rate and eviction rate; queue age, retries, and dead-letter volume; database saturation and replication lag.
- Recover deliberately: bound retries with deadlines and jitter, make writes idempotent, and use a degraded response that is explicit to the user.
- Name the next trigger: for example, "when peak writes exceed one primary's safe headroom" or "when a regional outage violates the availability target," revisit partitioning or failover.
Adding a queue, cache, or second datastore without a requirement introduces operational debt: more failure modes, more monitoring, and harder reconciliation. Name that cost when you propose the component.
Interview Close-Out Checklist
- Restate the product action, scope boundary, and invariant.
- Recap peak read/write load, retained data, and the SLO that drove the hardest decision.
- Walk the critical write and read paths, including their sources of truth.
- Name one failure response, one explicit trade-off, and one metric that would trigger the next design change.