System-design interview

1 · The method (you already have it) essential

Picture the failure mode, because you've probably watched it happen. A strong engineer gets "Design Twitter," goes quiet for ten seconds, then dives straight into database schemas. Twenty minutes later they've drawn a beautiful data model — and never asked how many users, never estimated the load, never mentioned the read/write skew that should have driven the whole thing. They knew every component cold and still failed the interview, because a system-design interview isn't a knowledge test. It's a process test: can you take a deliberately vague prompt and drive it to a defensible design under time pressure, thinking out loud the entire way?

That reframe is the single most important thing on this page. Think of the interviewer less as an examiner and more as a skeptical staff engineer you've been paired with for 45 minutes to whiteboard a system. They can't see inside your head — they can only grade what you say and draw. So the method isn't a checklist to recite; it's a way to make your reasoning visible and keep the conversation moving instead of stalling. The five steps below — requirements, estimate, API, data model, architecture — are just the natural order a good engineer would actually work in: figure out what you're building, how big it is, its interface, its data, then its shape.

Why does the order matter so much? Because each step feeds the next, and skipping one leaves the later ones ungrounded. You can't size storage before you know the retention window (a requirement). You can't pick "add a cache" convincingly until your estimate shows 40k reads/second. The classic mistake — and the fastest way to read as junior — is jumping to the fun part (architecture boxes) before the boring parts (scope and numbers) have earned you the right to draw them. The requirements and estimation steps feel slow, but they're what make every downstream choice defensible instead of arbitrary. Drive the sequence, narrate as you go, and manage the clock — roughly five minutes clarifying, five estimating, then the bulk on design with time reserved to deep-dive. The capstone trained the reasoning; this section is about performing it live.

The system-design interview flow

1. Requirements: functional + non-functional (scale, latency, consistency). Clarify first.
2. Estimate: users, QPS, storage — back-of-envelope (SD6).
3. API: the handful of endpoints.
4. Data model + shard key (SD2/SD7).
5. Architecture: client→LB→service→cache/DB (SD5); then scale the bottleneck.

2 · Estimation out loud essential

Here's the moment that separates candidates. The interviewer asks "how would you scale this?" and one candidate says "I'd add caching and sharding" — reasonable-sounding, but pulled from thin air. The other says "let me size it first: ten million daily users, ten actions each, so about 1,200 requests a second average, call it 3,500 at peak, and it's read-heavy so maybe 3,200 of those are reads — that's why I want a cache in front." The second answer isn't smarter. It's just grounded. Every design choice now points back to a number, and the interviewer can see you decide rather than guess.

Estimation intimidates people because it sounds like it demands precision or memorized constants. It demands neither. Think of it like a builder eyeballing a room before ordering materials — nobody expects the estimate to be exact, they expect it to be in the right ballpark and derived from stated assumptions. The whole game is orders of magnitude: is this 100 requests a second or 100,000? That difference changes your entire architecture; the difference between 3,400 and 3,600 changes nothing. So round aggressively, say your assumptions out loud ("assume 10 actions per user per day"), and let anyone challenge them — a challenged assumption you can defend reads far better than a suspiciously precise number you can't.

The mechanics are a short, repeatable chain, and it's worth internalizing because it's the same every time. Start from daily active users and actions each, divide by 86,400 (seconds in a day) to get average QPS. Multiply by a peak factor — traffic isn't flat, it clusters around evenings and events, so 3× to 10× the average is typical — to get peak QPS, which is what you must actually provision for. Then split by the read/write ratio, because reads and writes scale with completely different tools (replicas and caches absorb reads; sharding and queues absorb writes). A couple of useful anchors to keep in your head: there are ~86,400 seconds in a day and ~2.5 million in a month; a "byte-size a record" habit turns counts into storage. The critical discipline is the last one: after each number, say what it implies. "40k reads/second — that demands a cache." "3TB total — that fits comfortably in a sharded database." A number with no conclusion is trivia; a number that forces the next decision is engineering.

estimate.pydef estimate(dau, actions_per_day, read_write_ratio=10, peak=3):
    avg_qps = dau * actions_per_day / 86_400
    peak_qps = avg_qps * peak
    writes = peak_qps / (read_write_ratio + 1)
    reads = peak_qps - writes
    return {
        "avg_qps": round(avg_qps),
        "peak_qps": round(peak_qps),
        "peak_reads": round(reads),
        "peak_writes": round(writes),
    }

print(estimate(dau=10_000_000, actions_per_day=10))   # a big consumer app

{'avg_qps': 1157, 'peak_qps': 3472, 'peak_reads': 3157, 'peak_writes': 316}

3 · Cover the pillars intermediate

Now the part everyone thinks the interview is about — and where it's still easy to trip. You've scoped it, you've sized it, and now you get to draw the system. The temptation is to sketch one impressive component in loving detail and hope the interviewer is dazzled. But a design that's a gorgeous database schema with no API, or a clever caching layer with no story for how data gets written, reads as lopsided — it signals you can go deep on your favorite topic but can't hold a whole system in your head. The pillars exist to stop that: they're the four load-bearing pieces every online system has, and covering all of them (even briefly) proves you see the full picture before you zoom in.

Think of it like an architect presenting a building. Before arguing about the lobby marble, they show the plan: entrances (the API — how requests come in), the rooms and how they're laid out (the data model — what you store and your shard key), and how everything connects and holds weight (the architecture — client → load balancer → service → cache/DB). A client who only ever hears about the marble has no idea if the building will stand. Walk the pillars in that order and draw a box for each as you speak; the drawing keeps you and the interviewer synchronized on the same mental model, and it gives them something concrete to point at when they want to steer.

What turns a box-drawing exercise into a senior answer is that every box is justified by the numbers from step 2, not chosen by reflex. This is where the standard building blocks earn their place: a cache because your estimate showed the read path is hot (from SD5); read replicas to fan out those reads (SD6); sharding with consistent hashing because the write volume or data size exceeds one node (SD7); a message queue to decouple slow or bursty work — analytics, notifications — off the request's hot path (SD7). Naming a component is easy; the signal is saying why this one, here, for these numbers. And resist over-engineering: if your estimate says 40 writes a second, proposing a globally sharded multi-region write path is a red flag, not a strength. Match the machinery to the load you actually computed — that restraint is itself a seniority signal.

4 · Advanced — deep-dive a bottleneck advanced

There's a predictable pivot around the 25-minute mark, and candidates who don't expect it lose their footing. You've laid out the whole system, the interviewer nods, and then they say "let's go deeper on the cache" — or the sharding, or how the queue guarantees delivery. This is not them poking a hole; it's the most important part of the interview finally starting. Breadth showed you can architect a system. Depth shows whether you've actually operated one, or just memorized the boxes. Someone who has only read about caches can draw a cache; someone who has run one in production knows about invalidation, cold starts, and the thundering herd. The deep-dive is where that difference becomes audible.

Here's the mental shift: breadth is being a tour guide pointing at buildings; depth is being the structural engineer who can tell you exactly how one of them handles a load. When the interviewer picks a component, they hand you the microphone — and the single best move is to steer them toward the bottleneck your estimate already exposed. If your numbers screamed "40k reads a second," you should be eager to deep-dive the read cache, because you've earned the right to and you have specifics ready: the eviction policy, the TTL strategy, what happens on a miss, how you invalidate on writes. Driving the deep-dive toward the component that carries the load — rather than passively answering wherever they point — is a senior signal in itself.

What does "deep" actually mean in practice? It means moving from what to how and what-if. Not "I'd add a cache" but "it's a write-through cache keyed by the short ID, TTL of an hour with jitter so keys don't expire in lockstep, and on a miss I coalesce concurrent requests so one DB read serves them all." Not "I'd shard the database" but "I shard on user ID with consistent hashing, and here's how I handle a celebrity hot key that lands too much traffic on one shard." Concrete numbers, named strategies, and — crucially — the failure cases. Depth on one component with real tradeoffs always beats a shallow tour of ten. If you find yourself listing components again during the deep-dive, you've drifted back to breadth; pull yourself down into the mechanics of the one thing they asked about.

5 · Professional — tradeoffs & failure modes professional

Watch what happens when an interviewer hears an answer with no tradeoffs in it. A candidate says "I'll use SQL for strong consistency" and moves on, pleased. The interviewer's face doesn't change, but the score just capped. Not because SQL is wrong — it might be perfect — but because the candidate presented it as a fact rather than a choice. And every real engineering decision is a choice with a cost on the other side. Someone who says "SQL, done" either doesn't see the cost, or is hiding it. Someone who says "SQL, because I need transactions here and I'm willing to accept the write-scaling ceiling that comes with it" shows they see both sides and picked deliberately. That second sentence is the entire difference between a mid-level and a senior answer.

This is the deepest idea on the page, so it's worth stating plainly: in distributed systems there are no right answers, only tradeoffs. The CAP theorem (from SD6) makes it formal — when the network partitions, you must sacrifice either consistency or availability, you cannot keep both — but the principle is everywhere below CAP too. A cache buys read speed and pays with staleness. A queue buys decoupling and pays with eventual consistency and more moving parts. Sharding buys write scale and pays with cross-shard queries and rebalancing pain. The interviewer isn't looking for the option with no downside, because there isn't one. They're looking for whether you can name the downside you're accepting and justify it for this specific system. The tell of true seniority is volunteering the cost before you're asked, and naming the conditions under which you'd flip the choice ("if this were billing data instead of analytics, I'd pay the latency for strong consistency").

The second half of professional-grade reasoning is failure, and it's the half candidates most often skip because the happy path is so much more comfortable to talk about. But production systems spend their interesting moments failing, and interviewers know it. So for every component you draw, keep a reflex question loaded: what happens when this dies? When the cache node fails, do all reads stampede the database (a thundering herd)? When a shard goes down, do you lose that slice of users or fail over? When the queue backs up, do you drop messages or apply backpressure? A design that only describes the happy path is a demo, not a system. The professional move is to name the failure mode precisely — "thundering herd," "fail-open vs fail-closed," "split brain" — and offer layered mitigations rather than a single hopeful fix. Naming failure by its real name signals you've been on call for one.

6 · Tech-lead — the seniority ladder in the room tech-lead

Here's something that surprises people: two candidates can give the exact same design and get different grades. "Design a rate limiter." Both produce a correct token-bucket algorithm backed by a shared counter. One is passed as senior, the other as mid — with identical technical content. How? Because the level you're interviewing for changes the question you're actually answering. The design is the same; what the interviewer is listening for on top of it is not. Understanding this is what lets you aim your effort where it earns credit instead of over-explaining the parts that were already assumed.

The cleanest way to hold it is a ladder where each rung adds a layer instead of replacing one. Mid-level is correct: the right algorithm, the right data structure, the basic distributed case handled, the complexity known. That's a real bar and passing it is not nothing. Senior is correct under failure: everything mid did, plus what happens when the shared counter's Redis dies (fail-open or fail-closed — and that's a business decision, not a technical one), the synchronization overhead of a shared counter, and an algorithm choice defended with reasons. Staff and above is correct for the organization and the business: all of that, plus the product framing (rate-limit per user? per IP? per API key? what's the actual goal — abuse prevention, cost control, fairness?), the cost of running this as shared infrastructure many teams depend on, and how it rolls out safely with observability and tuning. Correct → correct-under-failure → correct-for-the-org. Notice you never abandon the lower rungs; you build on them.

Two practical consequences fall out of this. First, know which rung you're climbing to and reach one notch above comfortable — if you're targeting senior, don't stop at the working design and wait to be asked about failure; volunteer the failure analysis, because volunteering it (rather than being dragged to it) is itself the senior signal. Second, the highest rungs are less about deeper technology and more about widening the frame: from "does the code work" to "does it work when things break" to "is this the right thing to build for the company, and can an org actually operate it." That last move — pulling the conversation up to product goals, cost, and cross-team operability, and genuinely driving the whole discussion rather than answering questions — is what reads as staff. The technology ceiling is real, but the framing ceiling is usually what's actually being tested at the top.

Client
  |
  v
[API gateway] --write--> [App servers] --> [ID generator] --> [DB: id -> long_url, sharded]
  |                                              (base-62 counter / Snowflake-style)
  |--read (GET /abc123)--> [App] --> [Cache: id -> long_url]  --hit--> 301 redirect
                                         |--miss--> [DB] --> populate cache --> redirect
Analytics: click events --> [queue] --> async aggregation  (off the hot path)

Knowledge check check yourself