System design interviews — start here

You open the prompt: “Design a news feed.” Your instinct says draw boxes — API gateway, cache, database, done. The interviewer stops you: “Who are the users? How fresh does the feed need to be?” You realize you optimized for a diagram, not for the problem.

That moment is what system design interviews are built to surface. They are not a trivia test on which database a big company uses. They are a compressed version of early design work: vague ask, narrowing scope, proposing something coherent, and explaining what you would trade away to ship.

If this is your first time preparing, start here. This page gives you the rubric interviewers watch for, a four-step framework you can reuse on most prompts, and a 60-minute plan you can run today. For a longer weekly study plan, read How to Prepare for System Design Interviews.

---

What this interview is (and isn’t)

In the room, a system design interview feels like pairing with a senior engineer on a whiteboard — except they are mostly listening. You drive. They poke holes. They change a requirement mid-conversation to see whether your design bends or breaks.

It is a design exercise under time pressure. You move from requirements to decomposition to architecture to trade-offs. It is also a communication test: can someone who was not in your head follow the story?

It is not a quiz on the company’s internal stack. You are not expected to name every protocol or recite capacity numbers from memory. There is no single correct architecture. Two strong candidates can draw different systems and both pass — if each can defend their choices against the stated constraints.

The candidates who struggle often treat the session like a performance: recite a template, sprinkle buzzwords, hope the interviewer nods. The candidates who pass treat it like engineering: state assumptions, make decisions visible, and invite pushback.

---

What interviewers are really evaluating

Rubrics differ by company, but after many hiring loops, the same four signals show up. Think of them as the scorecard in the diagram above.

Problem navigation (requirements and scope)

Before you draw anything, you need a shared picture of the problem. That means a handful of targeted questions — not twenty, not zero.

Ask who the users are and what they do most often. Ask what is in scope and what is explicitly out. Ask what scale matters for this exercise: reads per second, data size, growth over a year. Ask what “good enough” reliability means — is occasional staleness acceptable, or not?

You do not need exact numbers from the interviewer. You need reasonable assumptions stated out loud: “I will assume 10k read QPS and one write per hundred reads unless you want me to stress-test writes.” Then your design should match those assumptions. When the interviewer says “actually, make it real-time,” you adjust — that is the point.

Solution design (a coherent system, not a collage)

A strong answer is a sequence of decisions, not a shopping list of technologies. Each box on the board should have a job. Data should flow in a story you can trace: client request, service boundary, storage, response.

Walk through the write path and the read path separately. Say where state lives and why. Mention cache, queue, replication, or sharding only when the requirements you agreed on need them — not because the diagram looks empty without them.

If an interviewer cannot tell which component owns which responsibility, the design is not finished yet. Clarity beats cleverness.

Technical depth (trade-offs and failure modes)

This is where interviews separate “I have seen a diagram” from “I have thought about production.” Name what breaks when load spikes: hot keys, fanout, lock contention. Say what happens when a dependency times out — retries, backpressure, degraded mode.

Pick a consistency level that fits the product and say where you relax it. Mention what you would measure: p99 latency, queue depth, error rate, cache hit ratio. You do not need a full observability platform on the board. You need to show that you know designs fail and you would notice.

Communication (clarity beats completeness)

You will not finish every detail in 45 minutes. Interviewers know that. They reward candidates who keep the conversation oriented: summarize the choice you just made, label the assumption behind it, and point to what you would deepen if you had more time.

“I am optimizing for read latency here, so I am accepting eventual consistency on the feed” is worth more than twelve unnamed boxes. If communication is your weak spot, read System Design as Communication — it goes deeper on the same skill.

---

A starter framework you can reuse

Most product-style prompts — feeds, short links, chat, file storage — fit the same loop. You do not need a different playbook for every company. You need one repeatable sequence you can run under pressure: clarify, name, draw small, defend trade-offs.

Picture a 45-minute session. The first ten minutes should not be boxes on a board. They should be you and the interviewer agreeing on what you are building and for whom. The next twenty minutes are a simple architecture that matches those constraints. The last fifteen are depth: scale, failures, and honest trade-offs. This framework maps directly to that rhythm.

Step 1: Clarify scope in 2–4 questions

Your first job is to turn a vague prompt into a bounded problem. Two to four good questions beat twelve mediocre ones. Each question should change what you would draw — not show off that you know buzzwords.

Start with who and what: who uses this system, and what is the one action that matters most? A URL shortener lives or dies on create-and-redirect. A feed lives on read volume and freshness. A chat system cares about delivery order and online presence. The core action tells you where to spend design time.

Then ask scale and freshness: how many users, reads, or writes matter for this exercise? Does data need to be real-time, or is a few seconds of delay acceptable? You are not looking for exact numbers. You are looking for an order of magnitude you can design against. Say it out loud: “I will assume 10k reads per second and one write per hundred reads unless you want me to stress writes.”

Finally, lock scope boundaries: what is explicitly out? “No analytics dashboard in v1.” “No multi-region in the first version.” “Search is out of scope — browse only.” Boundaries keep you from over-building and show the interviewer you can prioritize.

Questions that change architecture:

• “Is the feed global on day one, or region-first?” — changes replication and latency strategy
• “Do users need search and filters, or only chronological browse?” — changes indexing and storage
• “Must every read see the latest write, or is slight staleness OK?” — changes cache and consistency choices
• “Is this mobile-only, web-only, or both?” — changes API shape and client assumptions

Questions to skip: trivia that does not move the design (“Which exact HTTP status codes?”), or anything you could decide yourself without changing the architecture. If a question does not change a box on the board, save it for later.

A common mistake: spending five minutes on questions, then ignoring the answers and drawing a generic three-tier web app. Write your assumptions on the board. Refer back to them when you make choices.

Step 2: Name the core entities and APIs

Before you draw infrastructure, name the nouns and verbs of the system. This sounds basic. It is the step that separates a coherent design from a technology collage.

Entities are the things you store: User, Post, FeedItem, ShortLink, Message, Channel. You do not need a full schema yet. You need agreement on what exists in the problem domain. If you cannot list three to five entities in thirty seconds, you do not understand the prompt well enough to design yet.

APIs are the operations users or clients perform: create post, list feed, follow user, shorten URL, resolve redirect, send message. Write five to eight endpoints or operations — not fifty. Interviewers care that you know the read path vs the write path, not that you memorized REST naming conventions.

Example for “Design a news feed”:

Entity	Role
User	Account, follows other users
Post	Content a user creates
FeedItem	A post surfaced in someone’s feed (may include ranking metadata)

API / operation	Path type
Create post	Write
List home feed	Read (hot path)
Follow user	Write
Get user profile	Read

This table takes three minutes on the board. It forces clarity: the hot path is list home feed, so your read architecture, caching, and fanout story should center there — not on a generic “API layer” box.

This step prevents diagram-first chaos: drawing Redis, Kafka, and three microservices before anyone agrees what the system does. I have seen candidates lose ten minutes defending a “notification service” that the prompt never required. Name entities and APIs first; infrastructure second.

Step 3: Draw the smallest useful architecture

Now you draw — but the first diagram should be boring on purpose. Boring is easy to explain, easy to extend, and easy to fix when the interviewer adds a requirement.

Start with one end-to-end flow you could redraw from memory if the board were erased:

1. Clients (mobile, web — whatever you assumed in Step 1)
2. One entry point (API or backend service — one box, not six)
3. One primary datastore (SQL or document store — pick one and say why for this workload)
4. Optional cache — only if read volume or latency from Step 1 justifies it
5. Optional async path — only if writes must not block users (e.g. fanout to millions of followers)

Trace a single request out loud: “Client calls list feed → service loads feed IDs → joins post data → returns JSON.” Then trace a write: “Client creates post → service persists → feed update happens synchronously or via queue — here is why I picked one.”

Keep the first version to four to six boxes. If your initial diagram has fifteen components, you started too big. You can always add a read replica, a cache layer, or a queue when the interviewer asks “what happens at 10x traffic?” or “how do you handle celebrity users?”

Scale up only when asked or when your stated assumptions demand it. If you assumed 500 QPS, a single database and a cache may be enough. If the interviewer says “now assume a user with fifty million followers,” that is your cue to introduce fanout on write, a message queue, or a hybrid feed model — and to explain the trade-off of each.

Adding Kafka, Elasticsearch, and a CDN because “every design needs them” is a fast way to lose trust. Every component should answer: what problem does this solve given the constraints we agreed on?

Step 4: Talk trade-offs, not features

Interviewers do not reward a feature list. They reward judgment: why this choice, what it costs, what you would do when assumptions change.

For every major fork — database type, cache, sync vs async feed build, consistency level — say three things out loud:

1. What you are optimizing for — e.g. “I am optimizing for read latency on the home feed.”
2. What you are giving up — e.g. “I am accepting eventual consistency between write and feed visibility.”
3. What you would do next if scale doubles — e.g. “At higher fanout, I would move to write-time fanout with a queue instead of read-time aggregation.”

That three-part pattern turns a technology name into engineering reasoning. “We use Redis” is weak. “We cache feed pages because reads dominate writes; we accept stale feeds for up to thirty seconds; if hit rate drops we shard the cache by user ID” is strong.

Example trade-off table you can sketch mentally:

Choice	Gain	Cost
SQL for posts	Strong consistency, familiar queries	Harder to scale writes horizontally
Cache on feed	Fast reads	Staleness, invalidation complexity
Async fanout on post create	Fast write path for author	Complexity, delayed feed updates

You do not need to draw this table every time. You need to speak in gain/cost language when the interviewer probes.

End the design segment with a one-sentence summary: “Given our assumptions — read-heavy, slight staleness OK, single region — I optimized for simple reads with a cache and a single primary store; I would revisit fanout and sharding if follower counts or QPS grow tenfold.” That sentence signals senior communication, not memorization.

If you feel yourself reciting stacks instead of reasoning, pause and read System Design Without Memorization. Interviews reward thinking, not flashcards.

---

Your first 60 minutes (do this today)

Reading helps. Timed practice changes outcomes. Block an hour and run this once before you tweak your study plan.

Minutes 0–5: Skim this page. Do not take notes yet.

Minutes 5–40: Pick one prompt on Practice system design and run a timed session:

• 5 minutes — requirements and assumptions out loud
• 15 minutes — architecture: components, read path, write path
• 10 minutes — scaling and failure modes
• 5 minutes — trade-offs and “what I would do next”

Minutes 40–60: Write five bullets: what you missed, where you stalled, one assumption you should have stated earlier, one trade-off you skipped, one thing to fix on the next attempt.

That reflection is the prep. The diagram is just the artifact.

Repeat weekly: one problem, one reflection, one deliberate improvement. For a multi-week plan with study topics and pacing, use How to Prepare for System Design Interviews.

---

A quick note on numbers

Candidates often ask what constants they must memorize. Rough orders of magnitude are enough — milliseconds for a local network hop, tens of milliseconds for a cross-region call, that a day has 86,400 seconds. Interviewers care less about precision than about whether your math matches your assumptions.

A simple habit that reads as senior: when you state a number, say what it affects. “Ten thousand read QPS mostly hits throughput and cache sizing.” “A ten-year retention policy hits storage cost.” That one sentence shows intentional design instead of random guessing.

---

Where to go next

You now have the rubric, the loop, and one timed run to try. Stay in this cluster of essays if you are building a prep path:

• Software Engineer Interview Process: Every Round Explained — start-here map of OA, DSA, LLD, system design, AI, and behavioral
• How to Prepare for System Design Interviews — multi-week study plan and common mistakes
• System Design Without Memorization — why flashcards fail and what to do instead
• System Design as Communication — how to explain trade-offs so interviewers follow

When you want structured mental models before you practice, browse Design Thinking. When you want long-form system guides, start at System design reading. When you are ready to iterate with feedback, go to Practice system design.