Walk into the room with the whole design already in your head.
33 classic questions — Instagram, YouTube, the URL shortener, Uber and more — each solved the way strong candidates actually talk: requirements, estimates, API, data model, architecture, then the deep dives interviewers push on.
The whole set, grouped by what they're really testing.
Every big-tech loop draws from this pool. Filter by the kind of system, or go in order — difficulty ramps up.
Design a URL shortener
Base62 vs hashing, 301 vs 302, and a read path that must survive 100:1 fan-out.
Design Pastebin
A URL shortener where the payload is 10 MB — blob storage is the question.
Design a rate limiter
Token bucket vs sliding window, one atomicity race, and fail-open vs fail-closed.
ADesign search autocomplete
20× keystroke amplification, precomputed top-k tries, and an offline pipeline doing the real work.
A
Design a notification system
Never lose a notification, never send it twice — through providers you don't control.
Design a news feed
Precompute every feed and celebrities kill you; compute on read and latency does.
L
Design Twitter/X
300k timeline reads a second against 6k writes — plus IDs, search and trends.
A
Design Instagram
200 TB of media a day, and not one byte may touch your app servers.
SDesign WhatsApp
Guaranteed delivery over an unreliable bus, and 200M sockets that never touch the database.
MDesign Slack
Channels not conversations, threads not messages, and search that mustn't leak across workspaces.
Design Zoom
SFU beats mesh at 5, mesh beats MCU at 3, and the control plane never sees a byte of video.
MDesign YouTube
Segment everything: it's the one decision ABR, parallel transcode and the CDN all hang on.
Design Netflix
Pre-encoded, pre-placed, pre-warmed — Netflix's whole trick is doing everything before the play button.
ADDesign Dropbox
Chunked uploads, content-defined delta sync, and keeping bytes out of your services.
MDesign a distributed cache
O(1) LRU, consistent hashing, hot keys — and the discipline to not add durability.
Design a key-value store
Build the database itself: consistent hashing, quorums, and three kinds of failure repair.
Design a distributed lock
SET NX PX gets you 90% of the way; the last 10% is why Chubby, Zookeeper and etcd exist.
Design a web crawler
Crawl 10B pages in 5 days without DDoSing anyone or falling into a trap.
OADesign a message queue
Append-only logs, ISR replication, and why exactly-once is really at-least-once plus dedupe.
CDesign a job scheduler
Two-layer scheduling: a coarse DB poll feeding a precise delay queue, with at-least-once leases.
Design a metrics + monitoring system
Delta+gorilla compression, downsampling ladders, and why cardinality — not volume — is what kills you.
Design Yelp / nearby search
Geohash vs quadtree vs S2, the cell-boundary trap, and an index too small to shard.
Design Uber
2M location writes a second, and a lock that stops one driver getting two rides.
LGDesign DoorDash / Uber Eats
Geospatial matching, hedged assignment, dynamic ETAs, and a lifecycle that fails halfway through more often than you'd think.
Design Google Maps
100 PB of tiles, a world-scale road graph, and 3M location writes a second.
GDesign Ticketmaster
10M fans, 50k seats, zero double-sells — contention, not throughput.
Design a hotel booking system
3 TPS, zero double-bookings — inventory modelling and idempotency beat throughput.
ADesign Google Docs
Concurrent edits must converge: OT vs CRDT, one sequencer per doc, snapshots.
MFDesign a gaming leaderboard
Real-time rank for 25M players: sorted sets, and why SQL rank queries can't keep up.
Design a payment system
Exactly-once money from at-least-once parts: idempotency keys, a double-entry ledger, reconciliation.
ADesign Amazon
Read-optimised catalogue, session-cheap cart, strongly-consistent inventory, transactional checkout — one product, four different databases.
FDesign an ad click aggregator
Lambda architecture without saying 'lambda architecture' — plus exactly-once billing and fraud filtering.
Design a stock exchange
215k orders/sec, microsecond matching, one sequencer, and a log that is the database.
DThe concepts underneath
24 building blocks the questions keep reaching for. Each one: what it is, the variants, the numbers, and where the interviewer pushes.
Scalability
The root question behind every "design X at scale" prompt: the moment you say one server won't cut it, everything else — load balancing, sharding, caching — follows from that sentence.
InfrastructureLoad balancing
The first box you draw after "multiple servers" — and the box interviewers use to check you know the difference between L4 and L7, and what happens when it dies.
InfrastructureCaching
The highest-leverage move in system design: turn a 10 ms database read into a 100 µs memory read — and inherit three new failure modes for the privilege.
InfrastructureCDN
Physics you can't code around: cross-continent round trips cost 150 ms and the speed of light won't negotiate — so move the bytes to the user instead.
FundamentalsSharding & partitioning
The scaling move of last resort: split the data across machines and gain unlimited write headroom — while losing joins, transactions, and your ability to change your mind cheaply.
FundamentalsReplication & failover
Copies of your data on multiple nodes buy you read scale and survival — and a new physics problem: the copies are never quite the same at the same moment.
FundamentalsSQL vs NoSQL
Every design has a choose-your-database moment, and interviewers aren't scoring the choice — they're scoring whether it was derived from access patterns or from tribe membership.
FundamentalsDatabase indexes
The difference between a 1 ms lookup and a ten-second scan is a tree four levels deep — and every index you add taxes every write.
FundamentalsCAP & PACELC
Partition tolerance isn't optional, so CAP is really one question: when the network splits, do you serve stale data or serve errors?
FundamentalsConsistency & quorums
Once data lives on three replicas, "what does a read return?" stops being obvious — quorums, session guarantees and conflict handling are how you answer it.
InfrastructureConsistent hashing
hash(key) mod N reshuffles 90% of your keys when one node joins; a ring reshuffles 9% — that difference is a cache stampede avoided.
Realtime & messagingQueues & pub/sub
The standard answer to slow, bursty or failure-prone work — but a queue only buys time; if consumers can't keep up, you've hidden the problem, not solved it.
InfrastructureRate limiting algorithms
Five algorithms, one real decision: how much burst you allow, how much memory you spend, and what you do when the limiter itself falls over.
Realtime & messagingWebSockets, SSE & polling
HTTP only speaks when spoken to. Three ways to push data the other way — and the scoring is on picking the simplest one that works, not the fanciest.
FundamentalsAPI design
Five minutes of the interview is literally 'define the API' — and two follow-ups (pagination and idempotency) are where list endpoints and payment endpoints go to die.
InfrastructureUnique ID generation
Auto-increment dies the day you shard. The replacement must be unique, time-sortable and coordination-free — and 64 bits is all you get.
FundamentalsBloom filters & friends
Answer set, count and frequency questions on billions of items in kilobytes of memory — by accepting a small, bounded, one-sided error.
InfrastructureTimeouts, retries & breakers
The senior differentiator: after the happy path, every interview ends with "service B is slow — now what?" These four patterns are the answer.
FundamentalsEvent sourcing
Store the changes, not the state — a design decision that unlocks audit, time travel and rebuilds, and immediately makes every query harder.
InfrastructureChange data capture
Turn your primary database into a source of events without touching application code — the plumbing that lets one write feed a cache, a search index and an analytics warehouse.
FundamentalsGeohash, quadtree & S2
Three ways to turn 2D coordinates into a 1D index — and the reason your 'nearby' query does or doesn't scale.
Realtime & messagingStream processing
Continuous SQL over an infinite table — the model that makes 'aggregate the last five minutes' into a straight-line problem instead of a heroic batch job.
FundamentalsSaga pattern
The only way to run a transaction across services you can't hold a database lock across — a state machine with a defined undo for every step.
InfrastructureLeader election
Pick one node to be in charge — sounds easy, is a distributed-systems problem in disguise, and every 'exactly one worker' design hangs on it.
How every walkthrough is structured
The same seven steps, every time — because the interview itself rewards a repeatable shape.
- MIN 0–5
Requirements
Pin down functional scope and the non-functional numbers before touching boxes and arrows. This is where levels are set.
- MIN 5–10
Estimates, API, data model
Rough QPS and storage on one line each, the three endpoints that matter, and the entities with their database choice — said with reasons.
- MIN 10–20
High-level design
One diagram that satisfies every functional requirement. Walk a request through it out loud.
- MIN 20–35
Deep dives
Two or three hard parts, chosen by you before the interviewer chooses for you. This is where the interview is won.