Every system starts with a client asking a server for something. Requests and responses, statelessness, REST vs RPC, and status codes are the vocabulary of distributed systems — get these right and every later diagram makes sense.
Before you draw a single box, estimate the numbers: queries per second, storage per year, bandwidth, and how many servers that implies. Capacity math turns "it should scale" into a defensible design — and it is the first thing interviewers probe.
QPS estimation
Storage & bandwidth math
Powers of two
Peak vs average load
Build itEstimate the storage and QPS for a URL shortener serving 100M new links/month with a 100:1 read/write ratio. Show your working.
✓ CheckpointEstimate QPS and storage for a system out loud, and say which of your numbers you are least confident about.
The database is the heart of most designs. Relational (SQL) gives you joins, transactions, and strong schemas; NoSQL families — key-value, document, wide-column — trade some of that for scale and flexibility. Knowing when each fits is core.
Build itFor a chat app, decide where messages, user profiles, and presence each live — and justify SQL vs NoSQL for each.
✓ CheckpointPick SQL or NoSQL for one real workload and name what you gave up — every choice gives up something.
4
Caching
F4 · Intermediate · 45 min
A cache is the single highest-leverage tool for read-heavy systems: keep hot data in memory and spare the database. But caches bring their own problems — invalidation, staleness, eviction, and the thundering herd when they go cold.
One server is a single point of failure and a scaling ceiling. A load balancer spreads traffic across many, routes around unhealthy nodes, and lets you scale horizontally. Layer-4 vs layer-7, health checks, and sticky sessions are the knobs.
L4 vs L7
Round-robin / least-conns
Health checks
Sticky sessions
Build itSketch how a request reaches one of five app servers. Where does the load balancer sit, and what happens when a server fails a health check?
✓ CheckpointExplain the difference between L4 and L7 load balancing in terms of what the balancer can see.
6
CAP Theorem
F6 · Intermediate · 45 min
When a network partition hits, a distributed system must choose: stay consistent (reject some requests) or stay available (serve possibly-stale data). CAP names that unavoidable tradeoff, and it quietly drives most real design decisions.
Consistency vs availability
Partition tolerance
CP vs AP systems
Eventual consistency
Build itFor a shopping cart vs a bank ledger, argue whether you would lean CP or AP, and what the user sees during a partition.
✓ CheckpointExplain why CAP describes behaviour DURING a partition, and why choosing CP moves the failure rather than removing it.
When data outgrows one machine, you split it — by hash, by range, or by directory. Sharding scales writes and storage horizontally, but introduces hard problems: cross-shard queries, hot shards, and rebalancing as you grow.
Hash vs range partitioning
Shard keys
Hot spots
Rebalancing
Build itChoose a shard key for a social app's posts table. What query gets slow because of your choice, and how would you mitigate it?
✓ CheckpointPick a shard key for a real table and name the hotspot it creates. Every choice creates one somewhere.
Copies of your data buy availability and read scale — but now they can disagree. Leader/follower vs multi-leader, synchronous vs async replication, and the consistency models (strong, eventual, read-your-writes) are the tradeoffs to master.
Leader / follower
Sync vs async replication
Replication lag
Consistency models
Build itA user updates their profile, then immediately reloads and sees the old value. Explain the replication cause and two ways to fix it.
✓ CheckpointExplain what a reader can observe under async replication that they could not under sync, and what that costs.
Queues decouple producers from consumers: work is accepted fast, buffered, and processed asynchronously. They absorb spikes, enable fan-out, and add resilience — at the cost of new concerns like ordering, retries, and exactly-once delivery.
Async processing
Fan-out
At-least-once vs exactly-once
Backpressure
Build itRedesign a slow synchronous "send email on signup" flow with a queue. What happens if the email worker is down for an hour?
✓ CheckpointExplain why at-least-once delivery forces idempotent consumers, and what breaks if you assume exactly-once.
Naive hashing (key % N) reshuffles almost everything when you add or remove a server. Consistent hashing places nodes and keys on a ring so a change moves only a small slice of keys — the trick behind distributed caches and databases.
The hash ring
Virtual nodes
Minimal reshuffling
Load balancing keys
Build itWith 4 cache nodes on a ring, add a 5th. Roughly what fraction of keys move, and why is that better than key % N?
✓ CheckpointExplain what virtual nodes fix on a hash ring, and what a ring without them does when a node joins.
To protect a service from abuse and overload you cap how fast callers can hit it. Token bucket, leaky bucket, and sliding window each shape bursts differently — and doing it across a fleet of servers needs shared state.
Token / leaky bucket
Sliding window
Distributed counters
Per-user vs global limits
Build itDesign a 100-requests-per-minute-per-user limit that works across 10 API servers. Where does the counter live?
✓ CheckpointExplain why a fixed window lets a caller send 2× the limit across a boundary, and which algorithm fixes it.
How do independent nodes agree on a single value — who is the leader, what is the latest committed write — despite failures? Consensus (Raft, Paxos) and coordination primitives (quorums, leader election) are the backbone of reliable distributed systems.
Leader election
Quorums (N/R/W)
Raft / Paxos intuition
Split-brain
Build itWith 5 replicas, pick read and write quorum sizes that guarantee strong consistency. Why does R + W > N matter?
✓ CheckpointExplain what a quorum guarantees with N/R/W, and pick values for a read-heavy system.
The classic warm-up. Generate short unique keys, store the mapping, and serve billions of read-heavy redirects with low latency. Simple on the surface, it exercises key generation, caching, and read/write scaling.
Key generation
Read-heavy scaling
Caching redirects
Base62 encoding
Build itWalk the full design: how do you generate keys without collisions, and how do you serve a redirect in under 10ms at scale?
✓ CheckpointJustify your key-generation scheme for a URL shortener and say what breaks if two servers generate at once.
Aggregating posts from everyone you follow, ranked, in milliseconds. The core decision is fan-out on write vs read, and the celebrity problem — a user with 50M followers breaks the naive approach.
Fan-out on write vs read
Feed ranking
The celebrity problem
Precomputation
Build itDesign the feed for a user following 500 accounts. When would you precompute the feed, and how do you handle a celebrity post?
✓ CheckpointExplain the celebrity problem and why the push/pull threshold is a cost decision rather than a convention.
Real-time messaging with delivery guarantees, presence, ordering, and offline delivery. WebSockets vs long-polling, message storage, and the read-receipt problem make this a rich end-to-end design.
WebSockets & presence
Message ordering
Delivery guarantees
Offline queues
Build itDesign one-to-one chat: how does a message reach an offline user, and how do you guarantee it is delivered exactly once, in order?
✓ CheckpointExplain how you would order messages in a chat when two arrive from different servers at the same moment.
The canonical large-scale interview problem. Timelines, tweets, follows, and serving hundreds of thousands of reads per second — it ties together fan-out, caching, sharding, and the hybrid push/pull timeline.
Timeline generation
Hybrid push/pull
Sharding tweets
Read-heavy scale
Build itDesign the home timeline. When do you push a tweet to followers vs pull on read, and how do you mix the two?
✓ CheckpointExplain why a hybrid timeline beats pure push or pure pull, and which users each half serves.
Upload, transcode, store, and stream video to millions — YouTube-scale. Chunked upload, transcoding pipelines, CDN delivery, adaptive bitrate, and metadata at scale come together here.
Chunked upload
Transcoding pipeline
CDN & adaptive bitrate
Metadata at scale
Build itTrace a video from upload to playback: where does transcoding happen, and how does the CDN keep playback smooth on a bad connection?
✓ CheckpointExplain why video is transcoded into multiple renditions and what adaptive bitrate is choosing between.
Matching riders to nearby drivers in real time — Uber-scale. Geospatial indexing, live location updates, matching, and surge pricing make this a demanding real-time systems problem.
Geospatial indexing (geohash/quadtree)
Real-time location
Matching
Surge pricing
Build itDesign driver matching: how do you find nearby drivers fast, and how do you keep millions of live locations fresh?
✓ CheckpointExplain what a geospatial index gives you that a latitude/longitude index does not.
System Design roadmap — frequently asked questions
The common questions before you start — how long it takes, whether to follow it in order, and how it stays current.
How long does this roadmap take?
It runs 18 stations across 3 tracks — roughly ~16h of focused learning, plus the time you spend actually building. It is self-paced, so most people work through it over a few weeks, an evening or a single station at a time.
Do I have to follow the stations in order?
The tracks are ordered so each station builds on the one before, and following them start to finish is the intended path. But every station also stands alone — if you already have the foundations, jump straight to the part you need.
Is it free?
Yes. The whole roadmap, and every handbook, lab, and challenge it links to, is free and open — no sign-up and no paywall.
How is the roadmap kept current?
It teaches the durable fundamentals of the role first, then the tooling and the AI-era shifts on top — so most of it stays relevant as individual tools churn, and it is revised as the role itself changes.
Who is this roadmap for?
Anyone stepping into or leveling up in the System Design role — whether you are switching in, early-career, or a senior filling gaps. Start where you are; the ladder shows what is left.
Finished this one? 0 / 31 Roadmaps done
Explore the topic
See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.