Problem library
Eight systems, each with the numbers that matter.
A write-up that explains the choices, a diagram that names its own trade-offs, and a model you can push until something goes red. Every diagram opens in the playground as it is.
- 8
- problems
- 64
- components drawn
- 13
- workloads modelled
Track 1
Foundations
The three every interview assumes you know. Small systems with one big idea each: a read path that dwarfs its write path, a counter that has to be atomic, a ring that has to agree.
- URL Shortenereasy
Turn a long URL into a short code and redirect on lookup. The classic warm-up: tiny write path, enormous read path, and a key-generation problem hiding underneath.
- Rate Limitermedium
Decide, in under a millisecond and across a whole fleet, whether this request is allowed through. The algorithm choice and the counter-sharing problem are the two real questions.
Build the storage layer the other problems assume exists. Consistent hashing for placement, quorums for consistency, and an explicit answer to what happens during a partition.
Track 2
Products people use
Systems with a person on the other end. Connections that are held rather than served, fan-out that turns one write into thousands, and third parties that were never yours to scale.
- Chatmedium
Messages between people who are online now, and delivery for the ones who are not. The interesting part is that a connection is a resource you hold, not a request you serve.
- News Feedmedium
Show each user the recent posts of the people they follow. The whole design is one question: do the work when a post is written, or when a feed is read?
- Notification Systemmedium
Take events from every service and turn them into push, email and SMS — through providers you do not control, without sending anything twice.
Track 3
Scale machinery
Pipelines rather than request paths. A frontier that must be polite, a fetch that is mostly waiting, and a byte stream so large the API is a footnote.
- Web Crawlerhard
Fetch billions of pages without hammering any one site, fetching the same page twice, or losing your place. The hard part is the queue, not the fetch.
- Video Streaminghard
Upload once, transcode into a ladder of qualities, and serve millions of viewers from the edge. Bytes are the problem; the API is an afterthought.
Your own system is a problem too.
The same engine that judges these designs judges yours. Draw it, declare the traffic, and find out what breaks first.
Open the playground