Home › Guides › System design interview questions
Tech Explained · 2026System Design Interview Questions 2026: 12 Real Questions, Model Answers and the Numbers You Need
System design interview questions ask you to build a system under stated constraints: a URL shortener, a rate limiter, a news feed. A typical round runs 45 to 60 minutes and moves through requirements, traffic estimates, a high-level diagram, one deep dive and tradeoffs. Interviewers score your reasoning, not your recall of a reference architecture.
- The round is 45 to 60 minutes. It splits into requirements, estimates, a diagram, one deep dive and tradeoffs, so budget your minutes out loud.
- Numbers beat vocabulary. Dividing by 2,592,000 seconds in a month turns a vague prompt into a concrete 1,157 reads per second design target.
- The read to write ratio decides the architecture. At 30 to 1 you buy a cache before you even think about a shard.
- Verify limits, do not recite them. AWS documents a 400 KB cap on a DynamoDB item and Redis gives you 30 MB free, which quietly rules out two popular shortcuts.
- One mechanism owned at byte level scores higher than six managed services named in a row.
- Name the tradeoff yourself. A design you will not argue against reads as a design you have not understood.
- Most freshers never face this round. If your next interview is a first job at a services company, put your hours into coding instead.
You can explain Kafka. You have read about sharding. And you still stalled twenty minutes into the round when the interviewer said "walk me through what happens when the cache is cold." That gap is not knowledge. It is that nobody ever made you say a design out loud, with numbers, against a clock.
Keep one person in mind through this guide: a 2021-batch backend developer in Pune, four years on a services account, Spring Boot and MySQL, now interviewing at two product companies. They have roughly 30 spare hours a month. Everything below is sized for that budget.
How a System Design Interview Round Actually Works in 2026
Prep sites broadly agree on the shape of the round. The Design Gurus 2026 interview guide and Aced's 2026 guide both describe a 45 to 60 minute session that runs clarify, estimate, design, deep dive, tradeoffs. Two details matter more than the structure.
First, the level changes the weighting. Aced's guide on Google's system design interview notes that at L3 and L4 the design discussion is often folded into a coding round, and only becomes a heavy standalone round from L5. Second, Google's interviewers reportedly want you to build the component rather than name a managed service. That single preference invalidates half of what candidates rehearse.
The 2026 addition is generative AI prompts. Design a retrieval pipeline, design LLM inference serving. Some prep sites claim these now make up half of senior rounds, which is an unsourced number and you should not plan around it. Treat them as one more prompt family, not a replacement for the classics.
What one round looks like from the inside
Four facts worth internalising before you book a mock interview
Round shape from Design Gurus and Aced 2026 interview guides, checked 6 November 2026.
| Phase | Minutes | What the interviewer is actually scoring |
|---|---|---|
| Requirements and scope | 5 to 8 | Whether you narrow the problem before you draw anything |
| Scale estimates | 3 to 5 | Whether numbers drive your choices or decorate them |
| High-level design | 10 to 15 | Whether data flows end to end with no silent gaps |
| One deep dive | 10 to 15 | Whether you own a mechanism down to bytes and failure modes |
| Tradeoffs and failure | 5 to 8 | Whether you can argue against your own design |
System Design Interview Preparation: The Numbers to Have Memorised
Good system design interview preparation is mostly arithmetic you can do without a calculator. If you cannot convert a monthly figure into requests per second in your head, every later decision becomes a guess dressed as a principle.
Two of the numbers below are documented hard limits rather than rules of thumb, and both catch candidates out. The AWS DynamoDB developer guide states the maximum item size is 400 KB, counting attribute names as well as values, and caps any single expression string at 4 KB. So the popular answer of "store the click history inside the link item" fails at scale, and saying that out loud is worth more than the design itself. Redis Cloud's own Essentials plan documentation lists the free database at 30 MB, which is roughly 120,000 short-link entries: a demo, not a cache tier.
If you are also sitting a cloud exam, this arithmetic is the same arithmetic the architecture domains test, and it is practised live in 360DT's AWS Solutions Architect and DevOps course alongside SAA-C03 design scenarios.
| Number | Value | Why it decides a design |
|---|---|---|
| Seconds in a 30-day month | 2,592,000 | The divisor in every estimate you will ever do in a round |
| Memory read | order of 100 ns | A cache hit is effectively free next to anything on disk |
| SSD random read | order of 100 µs | Roughly a thousand times slower than memory, still fast |
| Same-region round trip | order of 0.5 ms | Chatty service calls, not CPU, cause most p99 blowouts |
| India to US round trip | order of 200 ms | Decides whether you replicate data or accept the latency |
| DynamoDB max item size | 400 KB | Documented cap; append-only logs inside one item will hit it |
| Redis Cloud free database | 30 MB | About 120,000 entries, so plan a paid tier or plan differently |
The four latency rows are orders of magnitude, not benchmarks. Quote them as orders of magnitude in the round too, because an interviewer who hears "about 100 microseconds" trusts you more than one who hears a suspiciously exact figure.
Also read: What Is Load Balancing? How It Works, 6 Algorithms and Load Balancer vs Reverse Proxy, which covers the component you will place first in almost every diagram.
Back of the Envelope Estimation: A URL Shortener Worked in 90 Seconds
Here is the whole of back of the envelope estimation, done on the most common prompt in the set. The interviewer says: build a URL shortener, assume 100 million new links a month and 3 billion redirects a month. You write six lines and stop.
writes = 100_000_000 / (30 * 24 * 3600) # 38.6 per second
reads = 3_000_000_000 / (30 * 24 * 3600) # 1,157 per second
ratio = reads / writes # 30 to 1
row = 7 + 200 + 32 # 239 bytes, budget 500 with indexes
year = 100_000_000 * 12 * 500 # 600,000,000,000 bytes = 600 GB
keys = 62 ** 7 # 3,521,614,606,208 codes availableThose six lines settle four arguments before they start. Thirty-eight writes per second is one unremarkable database, so stop talking about write sharding. Seven base62 characters give you 3.5 trillion codes, which at this rate lasts centuries, so stop debating code length. Six hundred gigabytes a year means five years of history fits on one large instance, so stop drawing a sharded cluster. And a 30 to 1 read ratio tells you exactly where your money goes.
The ratio that writes the architecture for you
Thirty reads for every write is the only number you need before choosing components
At roughly thirty reads per write, caching and read replicas carry the load, and write sharding is a solution to a problem this system does not have yet.
Derived from the stated 100 million writes and 3 billion reads a month, arithmetic shown above, 6 November 2026.
How to design a URL shortener without the usual trap
Most candidates answer "how to design a URL shortener" by hashing the long URL with MD5 and truncating. That works until two URLs collide, and then every write needs a read first to check. The cleaner answer is a counter: a ticket service hands each application node a block of 10,000 integers, the node encodes them in base62, and a write becomes a single insert with no read.
The catch is that sequential integers produce guessable codes, so you permute the integer before encoding it. Say that out loud. An interviewer who hears you find and close your own hole stops probing.
ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
def encode(n: int) -> str:
out = []
while n:
n, rem = divmod(n, 62)
out.append(ALPHABET[rem])
return "".join(reversed(out)) or ALPHABET[0]
encode(62 ** 7 - 1) # 'ZZZZZZZ', the last code in the 7-character space
encode(1) # '1'Read and write paths for 1,157 redirects per second
The split at the edge is the whole design; everything right of it is sized by the ratio
Throughput figures derived from the estimate above; Postgres 18 is the current stable major version per postgresql.org, checked 6 November 2026.
6 System Design Interview Questions on Scale and Storage, With Model Answers
These are the prompts that recur across the 2026 prep lists, including the Design Gurus and Aced guides above. For each one, the model answer below is the reasoning an interviewer wants to hear, not a finished architecture.
1. Design a URL shortener for 3 billion redirects a month
Answer with the estimate first, then one decision: counter-based code allocation over hashing, because it makes a write a single insert instead of a read plus an insert. Then the cache sizing. Ten million hot entries at about 250 bytes each is 2.5 GB of Redis, which is why the 30 MB free tier is irrelevant here. Close on the failure mode: if the allocator dies mid-block, you lose up to 10,000 codes out of 3.5 trillion, and that is an acceptable leak.
2. Design a rate limiter for a public API at 10,000 requests per second
Name three algorithms and pick one. Fixed window is one counter per user per window and leaks a double burst at the boundary. Sliding window log is exact and stores every timestamp, so memory grows with traffic. Token bucket is the usual answer because it absorbs bursts within a budget. A fixed window in Redis is two commands, and it is worth showing why that is not quite enough.
$ redis-cli
127.0.0.1:6379> INCR rl:user:42:1762400000
(integer) 1
127.0.0.1:6379> EXPIRE rl:user:42:1762400000 60
(integer) 1Two commands are two round trips, so a client can slip through between them. The production answer is one Lua script so the increment and the expiry are atomic. Memory is the easy part: one million active users at roughly 48 bytes per key is under 50 MB.
3. Design the write path for a payments ledger that must never lose an entry
This is the prompt that separates people who have run production from people who have read about it. Append-only double-entry rows, an idempotency key enforced by a unique index so a client retry cannot double-post, and an outbox table in the same transaction as the ledger insert so downstream events cannot be published for a transaction that rolled back.
The tradeoff you must volunteer: a single running-balance row per account serialises writes for that account. You either accept the ceiling or recompute balances from events. Version currency matters here too, because postgresql.org lists PostgreSQL 14 as losing fixes on 12 November 2026, which makes "we are on 14" a live risk rather than trivia. Architecture decisions of exactly this shape are what the AZ-305 domains examine, and they are worked through live in 360DT's Azure Solutions Architect and DevOps course.
4. Design a news feed for 50 million users
Fan-out on write precomputes each follower's feed and makes reads trivial, until one account with 20 million followers forces 20 million writes for one post. Fan-out on read keeps writes cheap and makes every feed load a scatter-gather. The answer that scores is the hybrid: push for ordinary accounts, pull at read time for accounts above a follower threshold you name, say 100,000. Naming the threshold is the signal.
5. Design a retrieval pipeline over 2 million internal documents
The generative AI prompt. Walk the pipeline: chunking strategy and why fixed 512-token chunks lose table context, an embedding store, hybrid retrieval combining vectors with keyword search because pure vector search fails on exact identifiers like invoice numbers, then a reranker over the top 50. Then say the part most candidates skip: without an evaluation set of a few hundred labelled questions you cannot tell whether a change helped. Retrieval and agent work of this kind is the core of 360DT's AI Engineer course.
6. Design an event pipeline for 200,000 clickstream events per second
Partition count and partition key, in that order. The key decides whether your consumers balance or one partition carries half the traffic, and user ID is usually right while country is usually wrong. Apache's release announcements list Kafka 4.3.0, published in May 2026, so if you cite a version, cite that one. Then commit semantics: at-least-once delivery plus an idempotent sink is simpler and cheaper than exactly-once, and in an interview you should say which you chose and why. Streaming pipelines like this are built in a live Microsoft Fabric data engineering programme.
Also read: What Is Apache Kafka? How Topics, Partitions and Consumer Groups Actually Work before you attempt this prompt out loud.
What each scaling step removes from the database
The same 1,157 reads per second, after each layer you add
Single primary
Two read replicas
Redis at 92% hit
CDN on redirects
Arithmetic on the estimate above, assuming a 92% cache hit rate and a CDN absorbing 70% of the remainder, 6 November 2026.
Practise system design the way interviews test it, on real cloud infrastructure
A live weekend programme over 12 weeks that prepares you for both AWS Solutions Architect Associate (SAA-C03) and AWS DevOps Engineer Professional (DOP-C02). It includes hands on projects, mentor support and placement guidance.
Explore the course
6 Rapid-Fire System Design Interview Questions That Probe Your Depth
These are the follow-ups, and they are where the round is usually decided. Each answer below is roughly what you should be able to say in forty seconds.
You added a read replica and a user cannot see their own edit. Why?
Replication lag. The write landed on the primary, the read went to a replica that has not applied it yet. The fix is read-your-writes: pin that user's session to the primary for a few seconds after a write, or carry the write's log position in the session and route to a replica that has caught up.
Why is p99 latency more useful than an average?
Because fan-out multiplies the tail. If one page makes 100 sub-requests and each has a p99 of one second, the chance that at least one is slow is one minus 0.99 to the power 100, which is about 63%. So nearly two thirds of page loads see a one second component even though 99% of calls are fast. Tail latency is also most of what instrumentation work exists to catch, which is why it sits inside the AI-300 operations domains covered in 360DT's MLOps Engineer course.
When would you not shard?
Almost always, at the scale most Indian product teams actually run. Sharding costs you cross-shard joins, distributed transactions and a migration you cannot easily undo. A single large managed Postgres instance with replicas comfortably serves the 600 GB a year our worked example generates. Say "I would not shard this" when the numbers say so; candidates who shard a 38 writes per second system are showing they did not read their own estimate.
What is the difference between a load balancer and an API gateway?
A load balancer distributes connections across healthy instances and mostly cares about L4 and L7 routing. An API gateway terminates the client contract: authentication, rate limiting, request validation, versioning, response shaping. You normally have both, with the balancer in front of the gateway fleet.
How do you make a retry safe?
An idempotency key the server stores and checks, so a repeat is a lookup rather than a second action. Then exponential backoff with jitter, because synchronised retries from thousands of clients turn one slow dependency into an outage. A retry budget caps the amplification: no more than 10% of traffic may be retries.
Your cache and your database disagree. What now?
Decide how stale is acceptable, then pick a mechanism that matches. Cache-aside with a short TTL accepts bounded staleness and is right for a redirect service. Write-through keeps them aligned at the cost of write latency. Explicit invalidation looks precise and races with concurrent reads under load. The honest answer in most rounds is bounded staleness with a stated bound.
6 Mistakes That End the Round Early
The Pune developer from the start of this guide failed their first design round, and not on knowledge. They drew eleven boxes in the first four minutes.
The six failures interviewers see most
Each one is a habit, which means each one is fixable in a week
Drawing before scoping
Boxes appear in minute two and the requirements never get narrowed. Ask what you are optimising and what you may ignore, then draw.
Phase 1Naming a service instead of a mechanism
"I would use a managed queue" answers nothing. Some interviewers, Google's reportedly among them, want you to build the component.
MechanismNo numbers at all
Without an estimate every choice is taste. Two minutes of arithmetic buys you the right to say "this does not need sharding".
EstimatesDesigning for 100 times the stated scale
Multi-region active-active for 38 writes a second reads as pattern matching. Build for the brief, then describe the next step.
OverbuildGoing quiet in the deep dive
Candidates drift back up to the diagram when pushed down into one component. Stay down there and talk about bytes, indexes and retries.
Phase 4Refusing to name a tradeoff
Every answer sounds optimal, so none sounds considered. Volunteer the weakness in your own design before the interviewer finds it.
Phase 5Failure patterns compiled from the 2026 interview guides cited above, checked 6 November 2026.
The deep dive is the part people practise least and lose on most. The interviewer says "tell me more about the cache" and the candidate answers with the diagram again: "so the read service checks Redis, and if it misses it goes to the replica." That is a restatement, not an answer. What they wanted was the key format, the entry size, the TTL, the eviction policy, what a cold start does to the database, and whether a stampede on one hot code can take the origin down. Practise one component to that depth and you will out-answer people who know far more than you do.
How to Prepare in Three Weeks With 30 Hours
Here is what I would actually do with that budget, and it is not what most prep advice says. Spend 20 of the 30 hours on four prompts, each done out loud, timed at 45 minutes, recorded, then watched back once. Spend 6 hours reading about the two components you were weakest on, which for most backend developers is caching and partitioning. Spend the last 4 on the arithmetic until the table above needs no lookup.
What I would skip: reading forty reference architectures, and paying for mock interviews before you can get through a URL shortener without stalling. The tradeoff I am accepting is breadth. You will meet a prompt you have not seen. You will handle it, because the framework transfers and the memorised architecture would not have.
And the honest caveat: this round rewards performance as much as engineering. Strong engineers who have never narrated a design fail it, and weaker candidates who have rehearsed four prompts pass. If your next interview is for a first job at a services company, this round probably will not appear at all and your hours belong in coding and SQL instead. Check the full certifications overview if you want the structured route, or sit in on a free webinar before you commit money to anything.
Also read: What Is Microservices Architecture? How It Works, Microservices vs Monolith and a Worked Example, which is the service boundary argument you will be asked to defend.
Related guides
- AWS Solutions Architect Interview Questions 2026 the cloud-specific round that usually sits beside this one in the same loop.
- Tier 3 College to Product Based Company in India 2026 how to get to the interview in the first place, including the resume screens.
- Docker vs Kubernetes in 2026 settles the container question that comes up inside almost every deployment deep dive.
- Site Reliability Engineer Salary in India 2026 what the roles that interview this way actually pay.
- Startup vs MNC in 2026 useful once you have two offers and very different design cultures to choose between.
- Cloud Engineer Jobs in Gurgaon 2026 where the BFSI employers who run this round are concentrated.
Frequently asked questions
What are the most common system design interview questions?
Across the 2026 prep guides the recurring set is a URL shortener, a rate limiter, a chat system, a news feed, an autocomplete or typeahead service, a key-value store and a payments or ledger write path. Since 2025 a retrieval pipeline or an LLM serving design has joined the list at AI-first companies. Four prompts practised properly cover most of the ground.
How long is a system design interview round?
Usually 45 to 60 minutes including introductions. Amazon sometimes compresses it into a 20 minute section inside a behavioural round, so ask the recruiter for the format. Budget roughly 8 minutes on requirements, 5 on estimates, 15 on the high-level design, 15 on one deep dive and the rest on tradeoffs.
How do I prepare for a system design interview with no production experience?
Build one small thing with real limits instead of reading about large ones. Put a cache in front of a database and measure the hit rate. Break something on purpose, then fix it. Interviewers can tell the difference between someone who has read about replication lag and someone who has watched a stale read appear on their own screen.
Do freshers get system design interviews in India?
Rarely as a standalone round. At entry level the design discussion is usually folded into a coding round as a few follow-up questions, which matches how Google reportedly handles L3 and L4. Dedicated design rounds show up from roughly three years of experience, and become decisive at senior and staff level.
Is back of the envelope estimation really expected in the round?
Yes, and it takes two minutes. Divide the monthly figure by 2,592,000 seconds to get requests per second, multiply the row size by the yearly row count for storage, then compare reads to writes. Nobody expects precision. They expect the number to then change what you build.
How to design a URL shortener in an interview?
Estimate first, then allocate codes from a counter rather than hashing the URL, so a write is a single insert. Encode the integer in base62 after permuting it so codes are not guessable. Seven characters give about 3.5 trillion codes. Then size the cache from the read to write ratio and finish on the failure mode when the allocator restarts.
Do system design interviews now include AI and RAG questions?
At AI-first companies, often. Prep sites report prompts to design a retrieval pipeline or LLM inference serving. One widely shared claim that these make up half of senior rounds has no published source behind it, so prepare one retrieval prompt properly and keep the classics sharp.
Should I memorise reference architectures?
No. A recited architecture collapses the moment the interviewer changes a constraint, and changing a constraint is exactly what they do. Memorise the arithmetic and three or four mechanisms you can discuss down to bytes, then derive the rest in the room.
About this guide. 360 Digital Transformation is an Anthropic Partner and a Microsoft Authorized Training Partner. Other certification bodies, vendors and employers named here are not affiliated with us. Tools and versions change quickly; commands and figures cited were checked on 6 November 2026.
Amazon Web Services
