System Design Interview Questions: Top 25 Problems with Answers (2026)
The top 25 system design interview questions for 2026, each with a short answer and the one follow-up that decides it — URL shortener, rate limiter, WhatsApp, Netflix, Uber, news feed, web crawler, object storage — plus the core concepts every round drills: consistent hashing, CAP theorem, SQL vs NoSQL, caching, and sharding. A framework-first prep guide for engineers heading into SDE and system design loops.
October 5, 202611 min read
System Design Interview Questions: the 2026 shortlist
Most system design prep goes wide and shallow — a hundred "design X" links, none of them finished. That is the opposite of how a real round works. Interviewers reuse a small set of problems, and inside each one they reach for the same handful of follow-ups: what breaks at scale, where the write goes when a node dies, which consistency you traded away.
This is the shortlist that actually repeats — 25 system design interview questions, grouped the way loops group them, each with a one-line answer and the follow-up that decides whether you pass. Before the list, there is a five-step framework that answers all 25, because the pattern is worth more than any single solution. Read it as a map: the design is table stakes, and the round is won on what you say when someone pushes back.
How a system design interview is actually scored
A system design interview is not a quiz with a right answer. It is a 45-to-60-minute conversation where you scope a vague prompt, sketch an architecture, and defend each choice while the interviewer digs. The same five moves carry every problem on this list, so learn the moves first.
The five-step framework that answers all 25
- Requirements. Turn the one-line prompt into functional and non-functional requirements. Ask clarifying questions out loud — they are scored on their own.
- Estimate. Back-of-the-envelope numbers: reads vs writes per second, storage over a few years. The reasoning matters more than the digits.
- High-level design. Client → load balancer → stateless services → cache → database, plus whatever the problem actually needs. Draw the happy path first.
- Deep dive. Pick the one hard part — unique ID generation, the hot partition, the consistency model — and go deep where the interviewer points.
- Follow-ups. Scale it 100×, kill a node, change the consistency requirement. This is where the round is won or lost.
On a live round the interviewer rarely lets you finish a sentence before asking "why that, and not the other thing?" That is the part a written solution can never rehearse — and the part these 25 questions are really testing.
What the debrief measures
Whatever the problem, the scorecard is the same four dimensions: Problem solving (do you see the failure mode?), Communication (do you narrate the tradeoff?), Technical execution (is the fix correct?), and Time management (do you reach the deep dive before the clock runs out?). Keep these in mind as you work the list — every question below maps back to them.
The 25 questions, by category
The 25 split into four groups. Warm-ups build the primitives every larger design reuses; product designs are the headline rounds; infrastructure problems test data-heavy scale; and the concept questions show up as follow-ups inside every single one.
| Group | Questions | What it tests |
|---|---|---|
| A. Building blocks | 1–6 | One primitive, done well: IDs, limits, caching, fan-out |
| B. Large-scale products | 7–16 | Scoping a whole product and picking the one hard part |
| C. Infrastructure & data | 17–21 | Throughput, pipelines, storage at scale |
| D. Concepts drilled in every round | 22–25 | The tradeoffs behind the boxes you drew |
Group A — Building-block questions (the warm-ups)
These are the phone-screen and mid-level favorites. Each is one primitive done cleanly, and each reappears as a component inside the bigger products — so nailing them pays off twice.
| # | Problem | The answer in one line | The follow-up that decides it |
|---|---|---|---|
| 1 | Design a URL shortener | Base62-encode a global counter; cache the read-heavy redirect path | "Two write servers, one counter — how do they agree on the next number?" |
| 2 | Design a rate limiter | Token bucket in a shared store (Redis); per-user key | "Token bucket or leaky bucket — and what happens on a burst?" |
| 3 | Design a key-value store | Consistent hashing for sharding, replication for availability | "A node dies mid-write — do you lose the write or serve a stale read?" |
| 4 | Design a distributed cache | LRU eviction, consistent hashing, write-through vs cache-aside | "How do you stop a thundering herd when a hot key expires?" |
| 5 | Design a notification system | A queue in front of per-channel workers (push/SMS/email); retries | "A provider is down — do you drop, retry, or reorder?" |
| 6 | Design Pastebin | Object store for blobs, metadata DB, short IDs, optional expiry | "A paste goes viral — how do you serve it without hitting the DB?" |
The moment you say "I'll keep a counter in Redis," a good interviewer asks what happens when you run two of them. Say the answer before they ask: one source of truth with atomic increments, or batched ID ranges per server.
Group B — Large-scale product questions
These are the headline rounds for onsite loops. The trap is scope: you cannot design all of WhatsApp in 45 minutes. State the requirements, draw the happy path, then spend your time on the one hard part the interviewer cares about.
| # | Problem | The one hard part | The follow-up that decides it |
|---|---|---|---|
| 7 | Design WhatsApp / chat | Delivery + presence over persistent connections | "The recipient is offline — where does the message wait, and for how long?" |
| 8 | Design a news feed (Instagram/Facebook) | Fan-out on write vs read | "A celebrity has 50M followers — do you still fan out on write?" |
| 9 | Design Netflix / video streaming | CDN + adaptive bitrate for a read-heavy catalog | "How does playback survive a regional CDN outage?" |
| 10 | Design Uber / ride-sharing | Geospatial matching of riders to nearby drivers | "How do you index driver locations that update every few seconds?" |
| 11 | Design Twitter | Timeline generation at fan-out scale | "Home timeline or user timeline — which do you precompute?" |
| 12 | Design YouTube | Upload → transcode pipeline + global delivery | "A 4K upload lands — walk me from bytes to a playable stream." |
| 13 | Design Google Docs | Real-time collaborative editing (OT or CRDT) | "Two people edit the same line at once — who wins, and why?" |
| 14 | Design Dropbox | File chunking, dedup, and sync across devices | "You changed one byte in a 2GB file — what actually uploads?" |
| 15 | Design Ticketmaster | Holding inventory under a flash-sale spike | "Two users grab the last seat in the same millisecond — what happens?" |
| 16 | Design a food delivery app (DoorDash) | Three-sided matching (eater, restaurant, courier) + live tracking | "The courier goes offline mid-delivery — how does the map stay honest?" |
Group C — Infrastructure & data-heavy questions
These test throughput and pipelines rather than product features. The senior signal is naming where the bottleneck moves as you scale, and choosing batch vs stream deliberately.
| # | Problem | The one hard part | The follow-up that decides it |
|---|---|---|---|
| 17 | Design a web crawler | Politeness, dedup, and a frontier that does not starve | "How do you avoid re-crawling the same page a million times?" |
| 18 | Design search autocomplete (typeahead) | A trie served from memory, ranked by frequency | "How do you refresh the rankings without a global rebuild?" |
| 19 | Design a distributed message queue | Ordering, at-least-once delivery, consumer groups | "A consumer crashes after reading but before acking — then what?" |
| 20 | Design an ad click aggregator | Real-time counting with late and duplicate events | "A click arrives an hour late — does your count still add up?" |
| 21 | Design Amazon S3 (object storage) | Durability, metadata indexing, and multipart uploads | "Eleven nines of durability — how, concretely, do you get there?" |
Interviewers love the "late event" and "duplicate event" follow-ups because they separate people who memorized a diagram from people who understand idempotency. If you can say why a dedup key or a watermark fixes it, you are already ahead.
Group D — Concept questions drilled in every round
These are not "design X" prompts — they are the tradeoffs an interviewer drills the instant you draw a box. Expect at least two of them inside any product design above.
| # | Concept | What to be able to say | Where it shows up |
|---|---|---|---|
| 22 | Consistent hashing | Why it beats modulo hashing when nodes come and go | Key-value stores, caches, sharded DBs |
| 23 | CAP theorem | During a partition you choose consistency or availability | Any replicated datastore |
| 24 | SQL vs NoSQL | Pick by access pattern and consistency need, not hype | Every data-model decision |
| 25 | Caching & sharding | Cache-aside vs write-through; shard key choice and hot partitions | Every read-heavy or large-data system |
How to prepare: a two-week plan
You do not need all 25 memorized. You need the framework automatic and a handful of problems you can defend under pressure. Here is a realistic two-week pass.
- Days 1–3: Drill the five-step framework on Group A. These are short enough to finish in 30 minutes, so you build the muscle without burning out.
- Days 4–8: One Group B product a day. Scope hard, draw the happy path, then force yourself to go deep on the "one hard part" column above.
- Days 9–11: Group C plus the Group D concepts. Write a two-sentence answer for consistent hashing, CAP, SQL vs NoSQL, and caching — out loud, not in your head.
- Days 12–14: Full mock rounds end to end. No notes. The goal is to hold the design together while someone interrupts.
The most common mistake in the last week is reading more solutions. Reading is not the bottleneck by day 12 — speaking is. If you have never said "I'd fan out on write, except for celebrities" out loud to a question, do that before you do another write-up.
The follow-ups that decide every round
Scan the right-hand column of every table above and a pattern jumps out: the questions rhyme. Master these five cross-cutting follow-ups and you are ready for problems that are not even on this list.
- "It works — now it's 100× the traffic. What breaks first?" → Name the bottleneck (a counter, a hot partition, a single DB) and the fix (batching, sharding, read replicas).
- "Where does the write go when the primary is down?" → Replication plus failover; accept bounded staleness or lose availability — your call, stated out loud.
- "Strong or eventual consistency here?" → Tie it to the user: a bank balance is strong, a like count is eventual.
- "A duplicate / late event arrives — is your count still correct?" → Idempotency keys, dedup, watermarks.
- "How do you shard this, and what's your hot-key plan?" → Shard key by access pattern; a secret for hot keys (salting, dedicated cache).
Each of these maps straight to the debrief: do you see the failure (problem solving), narrate the tradeoff (communication), fix it correctly (technical execution), and get there in time (time management)? Reading this list teaches you the answers. It does not teach you to deliver them while someone pushes back — that only comes from saying them out loud.
Frequently asked questions
What are the most common system design interview questions in 2026?
The repeat offenders are the building blocks (URL shortener, rate limiter, key-value store) and a rotating set of large products (chat, news feed, video streaming, ride-sharing). Phone screens lean on the warm-ups; onsite loops lean on the products. Underneath both, interviewers drill the same concepts — consistent hashing, CAP, SQL vs NoSQL, caching, and sharding — so prepare the concepts once and they pay off across every problem.
How do I answer a system design interview question I've never seen?
Fall back on the five-step framework: requirements, estimate, high-level design, deep dive, follow-ups. Scope the prompt with clarifying questions, draw the happy path, then ask the interviewer which part they want you to go deep on. A novel prompt almost always decomposes into primitives you already know — a queue, a cache, a sharded store — so you are rarely starting from zero.
How long does it take to prepare for a system design interview?
With focused practice, about two weeks is enough to be dangerous and four to six weeks to be comfortable, assuming you already know the basics of databases, caching, and networking. Depth beats breadth: being able to defend eight problems under follow-ups is worth more than skimming forty. Spend the back half of your prep on mock rounds, not more reading.
Do I need to memorize all 25 problems?
No. Memorizing solutions is the trap — interviewers change the numbers or add a constraint precisely to catch people who did. Internalize the framework and the five cross-cutting follow-ups instead, and keep a handful of problems you can defend deeply. The list is a map of the territory, not a set of flashcards.
What's the difference between high-level and low-level design interviews?
High-level design (HLD) is about the architecture of a whole system — services, data flow, scaling — which is what all 25 questions here cover. Low-level design (LLD) is about the classes, interfaces, and state of one component, like a parking lot or an elevator. Most SDE loops include both; if you are prepping LLD too, treat it as a separate track with its own patterns.
How do I practice system design interview questions out loud?
Reading a solution isn't the same as defending it while someone interrupts. On Zynter, each round is a live voice interview — you draw the architecture on a shared canvas and a voice interviewer asks the follow-ups above, one at a time, then gives you a debrief on problem solving, communication, technical execution, and time management. The rounds are modelled on how real company loops run, and the score is a practice signal, not a hiring decision.
Practise it on Zynter
You can read all 25 answers. The round is won on the follow-ups.
Pick a system design round, draw it on a shared canvas, and defend it out loud against a voice interviewer that keeps asking "what breaks first?" — then read the debrief. Zynter.ai is on-demand mock interviews for real company loops, with 150+ rounds across 20 companies (Sep 2026).
Practise a system design round → Browse all interview tracksAlmost nobody freezes on the code. They freeze on the follow-up.
Answer a real round to a voice interviewer that keeps asking why. No scheduling, no subscription, first session ready in under a minute.
