System design interviews test a skill that grinding LeetCode doesn't build: reasoning about distributed systems under ambiguity, at scale, in real time. This guide gives you a repeatable seven-step framework and a worked bank of eight classic prompts that account for the vast majority of what you'll actually face. Learn the pattern once and any new prompt becomes a matter of applying it.
What the round actually tests
System design rounds appear at Senior (L5 at Google and Meta, SDE II at Amazon) and above. Below that level the interview focus is on coding ability; from Senior up, companies need evidence that you can handle ambiguity, reason about trade-offs, and design for scale - skills that are much harder to fake than a memorised algorithm.
Interviewers are not looking for a single right answer. They are watching how you think: do you ask about scale before drawing boxes? Do you name trade-offs or pretend there is a free lunch? Do you know where the bottleneck will be and why? A candidate who produces a good diagram in silence will consistently score lower than one who produces an adequate diagram while narrating assumptions and trade-offs out loud.
The four axes interviewers score are: problem decomposition (did you break the problem down coherently?), technical depth (do you know the internals of the components you chose?), trade-off reasoning (did you name what you gave up with each decision?), and communication (did you drive the conversation, ask smart clarifying questions, and explain your thinking?).
For the building blocks you'll draw on - caching, sharding, queues, CAP theorem - see System Design Fundamentals. For how this round sits inside the full hiring loop, see FAANG Interview Process.
A repeatable answer framework
Every system design interview can be answered with the same seven-step skeleton. The order matters: each step unlocks the next. Skipping scope-setting to jump straight to the diagram is the most common reason candidates run out of time or design the wrong thing.
- 1
Clarify requirements & scope
Never skip3-5 minAsk: what are the core features and which are out of scope? Who are the users - consumers or internal systems? What consistency guarantees matter? Mobile or web or both? Framing wrong here means designing the wrong system for the next thirty minutes. - 2
Back-of-envelope estimation
Numbers first3-5 minEstimate daily active users, read/write ratio, peak QPS, storage per record, total storage, and bandwidth. Round aggressively - 100 million DAU, 100 bytes per record - and derive the numbers that will drive your design decisions. Interviewers who hear real numbers immediately trust your design more. - 3
API design
Contract3-5 minDefine the public interface: REST endpoints or RPC calls, request and response schemas, pagination strategy, and authentication surface. This anchors the data model and clarifies scope - asking whether a given endpoint needs to exist is a great way to sharpen requirements. - 4
Data model
Schema3-5 minIdentify the core entities and their relationships. Choose SQL vs NoSQL and justify it from the access patterns and consistency requirements, not from habit. Note which fields need indexes and whether you foresee needing to shard the table. - 5
High-level architecture
Draw it5-8 minSketch the boxes and arrows: clients, load balancer, app servers, caches, databases, queues, CDN, object store. Keep it simple - this is the skeleton. Label the key data flows and write approximate request rates on the hot paths. You want the interviewer to be able to follow it. - 6
Deep-dive the bottleneck
Go deep8-10 minPick the hardest component - the one that will not survive your estimated load without careful design - and go deep on it. This is where you earn senior signal: fan-out strategies, consistent hashing, write-ahead logs, leader election. Let the interviewer steer you to a different component if they want to probe elsewhere. - 7
Scale, failure & trade-offs
Close strong3-5 minRevisit your design at 10x scale: which component fails first? How do you handle a primary database failure, a network partition, or a hot shard? Name the consistency model you chose and what you gave up. A candidate who proactively surfaces failure modes signals staff-level thinking.
URL shortener & rate limiter
These two prompts are interview staples precisely because they are tractable yet reveal whether you understand write throughput, hashing, and distributed state. The URL shortener is the most common entry-level system design question; the rate limiter is the most common deep-dive add-on to any other design.
| Question | What it tests | Key considerations |
|---|---|---|
| Design a URL shortener (bit.ly) | Hashing, read/write asymmetry, redirect latency | Hash collision strategy: base62-encode an auto-incremented ID (no collisions, simple) or truncate MD5 and handle rare collisions with a retry. 301 vs 302: a 301 is cached by browsers indefinitely - most redirects never hit your servers - but you lose the ability to update the destination or collect analytics; 302 keeps control at the cost of every redirect hitting you. At scale the read path dominates; cache aggressively in CDN and Redis. Custom aliases need a unique index. Click analytics belong in an async pipeline, not the hot redirect path. |
| Design a rate limiter | Distributed counters, algorithm choice, concurrency | Choose the algorithm first: token bucket (smooth, handles bursts cleanly), sliding window log (precise but memory-heavy), sliding window counter (efficient approximation). In a distributed deployment, Redis with atomic INCR per key is the standard - but you trade strict accuracy for performance. Discuss placement: API gateway vs application layer. In multi-region setups, per-region buckets are eventually consistent; global buckets require coordination. Always raise the race condition: two concurrent requests can both read a counter of 0, both increment, and both proceed - exceeding the limit. A Redis Lua script that atomically increments and checks prevents this. |
Feed & timeline systems
News feed and Twitter timeline are the canonical questions for exploring the fan-out problem - the central architectural question of any social system. The choice between fan-out on write and fan-out on read is the crux, and the right answer depends on the distribution of follower counts in your user base.
| Question | What it tests | Key considerations |
|---|---|---|
| Design a news feed (Facebook / Instagram) | Fan-out strategy, ranking, read vs write amplification | Fan-out on write: when a user posts, precompute the feed for every follower at post time - fast reads, but writing to 50 million follower lists for a celebrity is prohibitively expensive. Fan-out on read: merge followed-user post streams at query time - simple writes, expensive reads at high follower counts. Production answer: a hybrid - fan-out on write for regular users, fan-out on read for accounts above a follower threshold (roughly 10,000 at Instagram). The ranking model sits outside the storage layer. Pagination uses a cursor, not an offset. |
| Design Twitter / X timeline | High-write throughput, the celebrity problem, eventual consistency | Tweets live in a distributed log; per-user timelines are precomputed sorted sets in Redis. On post, fan-out workers push tweet IDs into each follower's timeline cache. High-follower accounts are excluded from fan-out and merged in at read time from a separate celebrity feed store - this is the same hybrid that the real Twitter architecture uses. Likes and retweets propagate via async events and do not re-trigger a full fan-out. Eventual consistency on the timeline is intentional and acceptable. |
Real-time & media systems
Chat and video streaming pull in very different building blocks. Chat is a low-latency bi-directional messaging problem. Video streaming is a storage and delivery problem at massive scale. Each reveals a distinct slice of systems knowledge.
| Question | What it tests | Key considerations |
|---|---|---|
| Design a chat system (WhatsApp / Messenger) | WebSocket management, message ordering, delivery receipts, presence | Each client holds a persistent WebSocket to a connection gateway server (stateful). A routing layer maps user ID to gateway server - stored in Redis or ZooKeeper - so messages can be forwarded across machines. Message ordering: sequence numbers per conversation, not global, prevent out-of-order delivery. Delivery receipts (sent / delivered / read) are tracked asynchronously and pushed back to the sender via the same WebSocket. Presence uses heartbeats with a TTL in Redis. Group chat adds a fan-out step at send time. End-to-end encryption moves all key management to the client; the server sees only ciphertext. |
| Design YouTube / Netflix | Object storage, transcoding pipeline, CDN delivery, metadata vs content separation | Strictly separate hot metadata (title, views, comments - relational DB) from cold content (video bytes in object storage like S3). Upload flow: raw file lands in object storage, an async queue triggers transcoding workers that output multiple formats and resolutions (DASH/HLS). CDN edge nodes serve video bytes; the nearest point of presence dramatically reduces latency and origin load. Adaptive bitrate (ABR) streaming negotiates quality in real time based on the client's bandwidth. The search index (Elasticsearch or similar) is a separate system from the video metadata store - never conflate them. |
Specialized infrastructure: Uber & Dropbox
These two designs require domain-specific knowledge that generic prep rarely covers. Knowing the vocabulary alone - geohash, QuadTree, delta sync, chunked upload - immediately signals depth and often differentiates you from other senior candidates.
| Question | What it tests | Key considerations |
|---|---|---|
| Design Uber / find nearby drivers | Geospatial indexing, real-time location updates, trip state machine | Core problem: efficiently find all drivers within radius R of a point. Options: geohash (encode lat/lng as a grid-cell string, query by prefix), QuadTree (adaptive spatial partition that subdivides dense areas), or a PostGIS spatial index on Postgres. Driver location updates are high-frequency writes - push to a Redis geospatial index (GEOADD) with a TTL rather than writing to a relational database on every GPS ping. The matching service queries nearby available drivers and runs a dispatch algorithm. Model the trip as an explicit state machine: requested, accepted, en route, completed, cancelled - transitions are auditable events. |
| Design Dropbox / Google Drive | Chunked uploads, delta sync, conflict resolution, metadata vs content | Chunk files into fixed blocks (typically 4 MB) and hash each chunk. On sync, only upload blocks whose hash changed - this is delta sync and dramatically reduces bandwidth. A metadata service tracks the file tree, version history, and per-file chunk manifest. Chunk bytes go to object storage (S3). The sync client maintains a local change journal and receives remote change notifications via long-polling or WebSocket. Conflict resolution: last-writer-wins (simple) or create a conflict copy (the Dropbox approach - preserves both versions). Shared folders require distributed locking or optimistic concurrency on the manifest. |
What interviewers score - and the mistakes that sink candidates
Interviewers use a rubric, not a gut feeling. Understanding the rubric lets you engineer for it. Here is what strong candidates do and the failure modes that collapse scores without candidates realizing it.
What strong candidates do
- Drive the structure. They announce each phase ("let me start with requirements, then move to estimation"), ask one focused clarifying question at a time, and move the conversation forward without waiting to be led.
- Quantify everything. They never say "lots of users" - they say "100 million DAU, roughly 1,000 writes per second at peak, around 50 GB of new data per day" and use those numbers to drive design choices.
- Name trade-offs proactively. "I chose Redis for the timeline cache because reads are 100x writes and we can tolerate brief staleness on deletes - the cost is memory and cache invalidation complexity."
- Go deep voluntarily. They pick the hardest component and dive in before being prompted, demonstrating that they can identify the real engineering problem inside a design.
Mistakes that sink otherwise strong candidates
- Jumping to the diagram. Starting to draw before establishing scale and requirements means you may spend 30 minutes designing a 10,000-user system when the prompt implied 100 million.
- No numbers anywhere. Vague designs are unscoreable. "We'll add more servers" is not a design decision.
- Treating components as black boxes. Saying "put a cache here" without explaining the eviction policy, consistency model, or invalidation strategy signals surface-level knowledge.
- Ignoring failure modes. A design that only works when everything is healthy is an incomplete design. What happens when the primary database fails? When the queue backs up? When a shard goes hot?
- Silence. The single most common failure mode. If you are thinking, narrate it. Interviewers cannot score what they cannot observe.
Sources & further reading
- 1The System Design Primer — GitHub (donnemartin)
- 2Designing Data-Intensive Applications — Martin Kleppmann / dataintensive.net
- 3ByteByteGo - system design interview deep-dives — bytebytego.com
- 4High Scalability - real-world architecture case studies — highscalability.com