These system design interview questions are for engineering leaders hiring mid-level, senior and staff engineers, and for candidates preparing for the round that often decides the level of an offer. The first section tests the concepts every design draws on. The second gives full design prompts, each with the points a strong answer should reach. Use one full prompt per interview, plus two or three concept questions as warm-ups or follow-ups. Score the reasoning and the trade-offs, not whether the final diagram matches yours.
What a strong system design interview checks
- Scoping: turning a vague prompt into clear functional and non-functional requirements.
- Estimation: rough numbers for traffic, storage and bandwidth that shape the design.
- Building blocks: knowing what caches, queues, databases and load balancers are good and bad at.
- Trade-offs: consistency against availability, latency against cost, simplicity against scale.
- Failure thinking: what breaks, how you notice, and how the system recovers.
- Communication: a clear structure the interviewer can follow and challenge.
System design interview questions: core concepts
1. You get a one-line prompt: "Design a photo sharing app." What do you do in the first five minutes?
What good looks like: ask questions before drawing anything. Who uses it, which features are in scope (upload, feed, comments), how many users, read-to-write ratio, latency goals, and what matters most (availability, consistency, cost). Then write down the agreed requirements and a rough scale estimate.
Red flag: jumping straight to microservices and Kubernetes.
2. Estimate the request rate for 10 million daily users who each make 20 requests a day.
What good looks like: 200 million requests a day divided by about 86,400 seconds is roughly 2,300 requests a second on average. Peak is often two to three times that, so plan for 5,000 to 7,000. Strong candidates use the number to decide something, for example that one database can handle reads with caching but writes need a closer look.
3. Explain CAP in practical terms.
What good looks like: when a network partition happens, a distributed system must choose between staying consistent (refusing some requests) and staying available (serving possibly stale data). A strong answer adds PACELC: even without a partition, you trade latency against consistency. Examples: a bank balance leans toward consistency, while a like counter can be eventually consistent.
4. Compare cache-aside, write-through and write-back caching.
What good looks like: cache-aside, where the app reads from the cache and fills it from the database on a miss, is the most common and simple. Write-through updates the cache and database together, keeping the cache fresh at the cost of slower writes. Write-back writes to the cache first and flushes later, which is fast but risks data loss. Strong candidates raise cache stampedes, where many requests miss at once, and fixes like request coalescing and randomized TTLs.
5. How do you choose a shard key?
What good looks like: pick a key that spreads load evenly and keeps the most common queries on one shard, such as user ID for a user-centric app. Hash-based sharding spreads load well but makes range queries hard. Range-based sharding supports ranges but risks hot spots. Consistent hashing reduces how much data moves when shards are added. A strong answer names hot keys (a celebrity account) and the cost of cross-shard queries.
6. What problems does leader-follower replication introduce?
What good looks like: followers lag behind the leader, so a user can write and then read stale data from a replica. Fixes include reading your own writes from the leader for a short window or tracking the replication position. Failover needs care to avoid two leaders. Multi-leader setups add write conflicts that need a resolution rule.
7. What do at-most-once, at-least-once and exactly-once delivery mean?
What good looks like: at-most-once may lose messages, and at-least-once may deliver duplicates. True exactly-once delivery across systems is very hard, so in practice teams use at-least-once delivery with idempotent consumers that ignore duplicates by message ID. Ordering is usually guaranteed only within a partition, so choose the partition key around what must stay in order.
8. When would you pick a relational database over a document or wide-column store?
What good looks like: relational when you need transactions across rows, flexible queries and strong constraints, which covers most business apps. Document stores suit self-contained records with varied shapes. Wide-column stores suit huge write volumes with known access patterns. A strong answer starts from the access patterns and notes that a well-indexed relational database scales further than many teams expect.
System design interview questions: full designs
9. Design a rate limiter for a public API.
What good looks like: clarify limits (per user, per key, per IP) and where it runs (usually the API gateway). Compare token bucket, which allows short bursts, with sliding window counters, which are smoother. Keep counters in a shared fast store like Redis with atomic operations so all servers agree. Return 429 with a Retry-After header. Decide whether to fail open or closed if the store is down.
10. Design a notification service that sends email, SMS and push.
What good looks like: an API that accepts a notification event, a preferences service (channels, opt-outs, quiet hours), templates, and a queue per channel so a slow SMS provider doesn't block email. Workers retry with backoff, dedupe with an idempotency key, and can fail over to a second provider. Track delivery status for each message.
11. Design a chat system for one-to-one and small group messages.
What good looks like: clients hold a WebSocket to a gateway layer, and a lookup service tracks which gateway each user is connected to. Messages are stored partitioned by conversation, with a per-conversation sequence number for ordering. Offline users get push notifications and fetch missed messages on reconnect. Delivery is at-least-once, so clients dedupe by message ID. Strong candidates cover read receipts and typing indicators as lighter, lossy signals.
12. Design checkout so a customer is never charged twice.
What good looks like: the client sends an idempotency key with each payment attempt, and the server stores it with the result so a retry returns the original outcome. Model the order as a state machine (created, authorized, captured, failed). Write the payment intent before calling the provider. Run a daily reconciliation against the provider's records to catch anything the happy path missed.
Red flag: "We'll use a distributed transaction across our database and the payment provider."
13. Design search autocomplete.
What good looks like: a latency target near 100 milliseconds, so precompute the top suggestions per prefix offline from query logs and serve them from memory or a cache close to the user. A trie or prefix index works for the lookup. Update rankings in batches, filter unsafe terms, and debounce on the client to cut traffic.
14. Design a scheduler that runs millions of delayed jobs.
What good looks like: store jobs indexed by run time, often in time buckets. Workers claim due jobs with a lease (a visibility timeout), so a crashed worker's job becomes available again. Delivery is at-least-once, so jobs must be idempotent. Add retries with backoff, a dead-letter queue, and metrics on queue lag.
15. Design file sync across a user's devices.
What good looks like: split files into chunks and hash each one, so unchanged chunks aren't uploaded again and identical chunks dedupe. A metadata service tracks file versions and which chunks make up each one, while chunk data lives in object storage. Devices upload and download directly with signed URLs. Conflicting edits create a conflict copy rather than silently overwriting.
16. Design a metrics pipeline for thousands of services.
What good looks like: agents batch and send metrics to a durable buffer like Kafka, stream processors aggregate them, and a time-series database stores the results. Downsample older data (per-second for a day, per-minute for a month) and expire it by tier. A strong answer warns about label cardinality, where a user ID in a label can explode storage.
17. Design a social news feed.
What good looks like: compare fan-out on write (push each post into followers' feeds, fast to read) with fan-out on read (gather posts when the feed loads, cheap to write). Most real systems mix them: push for normal accounts, pull for accounts with huge followings. Cache the first page of each feed and rank with a separate service.
Behavioral (STAR)
18. Tell me about a system you designed that you would design differently now.
What good looks like: a specific system, the assumptions that turned out wrong (traffic shape, team size, data growth), what it cost, and the design they'd pick today. Good engineers can critique their own work without getting defensive.
19. Describe a time you balanced cost against reliability.
What good looks like: real numbers on both sides, such as the cost of a second region against the expected cost of downtime, how they made the case to decision-makers, and the outcome.
A simple scoring rubric
Running this interview with AI
System design is hard to screen at scale because it needs a senior interviewer and a whiteboard. NTRVSTA's system-design interviews include an interactive whiteboard, so candidates can sketch components while the AI interviewer asks follow-ups. The interviewer adapts in real time: a candidate who handles the basic design well gets pushed on sharding, failure modes or a changed requirement, while one who struggles stays on core building blocks.
Your senior engineers then review a score breakdown and video snippets of the key reasoning moments, and save their live time for the final round. Read how AI interviews are scored to see what an automated score can and can't tell you, and browse technical interview platforms or AI interview software to compare options. Pair this round with backend developer interview questions for a fuller picture.
Questions
How long should a system design interview be?
Plan 45 to 60 minutes for one design prompt. Use about 5 minutes for requirements, 10 for estimates and the API, 15 for the high-level design and 15 to 20 for a deep dive, with the rest for questions.
Should junior engineers get system design questions?
Usually a lighter version. Ask a junior to design one component, such as a rate limiter or a job queue, and score clear reasoning over breadth. Full end-to-end prompts with sharding and multi-region trade-offs fit senior and staff roles.
Is there one right answer to a system design question?
No. There are many good designs and some clearly bad ones. Score whether the candidate asked about requirements, chose components for stated reasons, and named the trade-offs of their choices.
See a system design round with a live whiteboard and an AI interviewer: book a 20-minute demo, or try a sample interview yourself today.
