The System Design Interview

The system design round is where senior offers are won or lost, and it’s the round strong coders most often under-prepare. There’s no single right answer — the interviewer is probing your judgment: can you take a vague prompt, impose structure, make trade-offs explicit, and defend them. The antidote to the round’s open-endedness is a time-boxed structure you drive yourself.

A structure for 45 minutes

1. 1

   Requirements5–8 min · functional + non-functional
   →
2. 2

   Estimation3–5 min · QPS, storage, bandwidth
   →
3. 3

   High-level design10–15 min · end-to-end path
   →
4. 4

   Deep dive10–15 min · trade-offs where steered
   →
5. 5

   Wrap-up3–5 min · bottlenecks, SPOFs, monitoring

Get a working end-to-end path before going deep anywhere.

1. Requirements (5–8 min). Pin down scope before drawing anything. Separate functional requirements (what it does) from non-functional ones (scale, latency, availability, consistency). Ask about the numbers: how many users, reads vs. writes, how much data. A design with no stated scale is un-gradeable — the whole point is designing for a load.

2. Estimation (3–5 min). Do the back-of-the-envelope math out loud. Requests per second, storage per year, bandwidth. You don’t need precision; you need to show you can size a system and let those numbers drive later decisions (“40k writes/sec means a single database won’t do — we’ll need sharding”).

3. High-level design (10–15 min). Sketch the major components and the data flow between them: clients, load balancer, services, databases, caches, queues. Get a working end-to-end path on the board before you go deep anywhere. Talk through the happy path of a core operation.

4. Deep dive (10–15 min). The interviewer will steer you into one or two areas. This is where seniority shows: the data model, how you shard, how you keep the cache consistent, how you handle a component failing. Name trade-offs explicitly — every choice you make closes off an alternative, and saying so is the signal.

5. Wrap-up (3–5 min). Name bottlenecks and how you’d scale past them, single points of failure, and what you’d monitor. Acknowledging your design’s limits reads as senior, not weak.

Junior candidates try to design the perfect system. Senior candidates design a reasonable system and are explicit about its trade-offs and failure modes. Interviewers are buying judgment, not perfection.

An AI-flavored example

AI SWE loops increasingly use AI-centric prompts: “Design a semantic search system,” “Design a system to serve an LLM chat product,” “Design a content moderation pipeline.” Everything above still applies — you just layer on the AI system-design discipline from the System Design module: the two-pipeline split (offline ingestion vs. online query), streaming to hide model latency, semantic caching to cut cost, and timeouts/fallbacks for an unreliable model provider. Doing the token-cost arithmetic out loud is a standout senior move.

Common failure modes

• Jumping to components before nailing requirements — you design the wrong system, confidently.
• No numbers — a design untethered from scale can’t be evaluated.
• Hand-waving the hard part — when pushed on consistency or failure, vague answers here cost the most.
• Ignoring the interviewer’s steer — they’re guiding you toward the signal they need; follow it.

Practice by designing a handful of canonical systems end to end — a URL shortener, a news feed, a rate limiter, a chat product, a RAG service — out loud, on a whiteboard, under a timer. Structure under pressure is a skill, and it’s built by reps.

Pattern recognition

Variations

Worked problems

MockHard

• RAG
• Time-boxing
• System design

Mock design: AI document search

Design a document search system for a company. Employees can upload internal PDFs, search across documents, and ask natural-language questions that return answers with citations. Permissions must be respected.

Approach. Drive the 45-minute structure yourself. Clarify scope, estimate traffic and storage, sketch the offline ingestion and online query paths, then deep dive on permissions, retrieval quality, and failure modes.

Show solution

A strong time-boxed walkthrough:

Time	What to cover
0–5 min: requirements	Users upload documents, search keyword/semantic, ask questions, receive cited answers. Non-functional: permission correctness, freshness, latency, availability, auditability. Ask whether cross-tenant search is forbidden and how quickly new docs must appear.
5–8 min: estimates	Size documents per day, chunks per document, query QPS, embedding storage, and LLM cost per query. Use rough numbers to decide whether indexing can be async and how much to cache.
8–18 min: high-level design	Upload service stores raw files in object storage and metadata in a database. Async pipeline extracts text, chunks, embeds, and writes to a vector index plus keyword index. Query service checks identity, retrieves permission-filtered chunks, reranks, builds prompt, calls model, and returns citations.
18–33 min: deep dive	Permissions: store ACL metadata per document and enforce before generation, not after. Retrieval: hybrid keyword plus vector search, reranking, chunk versioning. Freshness: async pipeline with status states. Reliability: timeouts, fallback to search results if generation fails.
33–40 min: bottlenecks	Hot documents, large tenants, embedding throughput, vector-index growth, LLM latency and cost. Cache retrieval for repeated queries where permissions match.
40–45 min: wrap	Monitor retrieval recall, citation coverage, answer latency, permission-denied attempts, ingestion lag, model errors, and user feedback.

The senior trade-off: permission filtering can happen before or after vector search. Pre-filtering is safer but can hurt recall or performance depending on index support. Post-filtering is simpler but risks empty results or accidental leakage if done incorrectly. For internal docs, correctness wins.

DrillMedium

• Time management
• Senior signal

Running out of time: what do you cut?

You are 32 minutes into a 45-minute system design interview. Requirements and the high-level design are done, but you have not covered deep dives, bottlenecks, or monitoring. The interviewer asks one detailed question about cache invalidation.

Approach. Do not get trapped in a ten-minute tangent. Answer the question at the right depth, then explicitly manage the remaining time and steer toward the highest-signal areas.

Show solution

A strong response:

“I’ll answer cache invalidation briefly, then I want to reserve the last ten minutes for failure modes and scaling bottlenecks. For this design, I would use TTL-based caching for read-heavy derived results and event-driven invalidation for objects with correctness requirements. The main risk is stale reads after writes, so I would either bypass cache on read-after-write paths or version cached values. Now let me zoom out to the bottlenecks and what I would monitor.”

What you cut:

Cut	Keep
Exhaustive API schemas	Core endpoints and data flow.
Every database column	Entities, indexes, partition keys.
Perfect cache policy	The correctness trade-off and invalidation trigger.
Minor component details	Bottlenecks, failure modes, monitoring.

Senior signal is not covering everything. It is choosing what matters while the clock is visible.

DrillMedium

• Trade-offs
• Interview strategy

Choose the deep dive

The prompt is “Design a global rate limiter for an API.” You have a working high-level design with edge proxies, a counter store, and a configuration service. The interviewer asks where you want to go deeper.

Approach. Pick the deep dive that exposes the core trade-off. For a rate limiter, that is not UI, and it is probably not generic load balancing. It is correctness vs. latency under distributed traffic.

Show solution

A strong answer:

“I’d like to deep dive on the counter algorithm and consistency model, because that’s where the design’s behavior is decided. We can compare fixed window, sliding window, and token bucket; then decide whether counters live at the edge, in a centralized store, or in regional stores with eventual reconciliation. The trade-off is strict global enforcement versus low latency and availability. For most public APIs I would accept slight overage during partitions to keep the API available, while using tighter limits for expensive or abusive operations.”

Why it works:

Choice	Signal
Names the core risk	You know what the system is really about.
Offers alternatives	You can compare designs, not just present one.
States the trade-off	You are making judgment visible.
Segments by operation	You avoid one-size-fits-all architecture.