Problem library
Grouped by the shape of the problem, not by product name. Two products that look different are often the same problem, and two that look alike often are not.
Read-heavy / caching
Few people write. Many read, and they read the same few things.
The tell: Your estimate comes back with reads outnumbering writes by 50x or more. The write path is a non-problem and you should say so out loud instead of designing it.
Same shape, different products: URL shortener · Pastebin · News feed read path · Leaderboard. Once you can do one of these, the others are the same five stages with different numbers.
Write-heavy / fan-out
One action by one person creates work for thousands of other people.
The tell: The question is always the same: do you do that work when they write, or when everyone else reads? And what do you do about the one user with 200 million followers?
Follower timeline
A reader cannot tell when a post was supposed to appear in their feed. So you have seconds of slack on delivery, and almost none on opening the app.
Chat and messaging
Two people are looking at the same screen expecting the message to appear. There is almost no slack on delivery. There is plenty on everything around it, and the design depends on using it.
Notification system
Almost every notification has slack. This system's value is that it takes the work off other teams' request paths and spends that slack for them.
Same shape, different products: Twitter timeline · Chat delivery · Notification system · Activity feed. Once you can do one of these, the others are the same five stages with different numbers.
Matching under time pressure
Two sides need to find each other, and one of them is a human who is waiting.
The tell: Supply moves, demand is impatient, and the interesting design is what happens when nobody accepts, rather than the happy path.
Same shape, different products: Ride hailing · Food delivery dispatch · Any two-sided marketplace. Once you can do one of these, the others are the same five stages with different numbers.
Contested inventory
A fixed number of things and more people who want them than there are things.
The tell: If two people can end up with the same one, you have failed, no matter how fast the system is. Caching the availability number is the classic wrong turn.
Same shape, different products: Ticket booking · Hotel booking · Flash sale · Seat reservation. Once you can do one of these, the others are the same five stages with different numbers.
Big files
The payload is far bigger than the metadata, and it should not go through your servers at all.
The tell: The moment you draw the file passing through your application server, you have made bandwidth your problem. Let the client talk to storage directly.
Same shape, different products: Video upload and playback · Cloud file storage · Image hosting. Once you can do one of these, the others are the same five stages with different numbers.
Live push
The server has to speak first, to a lot of people, at the same time.
The tell: Capacity is measured in concurrent connections, not requests per second, and the hard part is the fan-out layer, not the socket.
Same shape, different products: Live sports score · Live comments · Collaborative editor · Presence. Once you can do one of these, the others are the same five stages with different numbers.
Search and ranking
The user gives you a fragment and expects the right answer ranked first.
The tell: Two systems: one that narrows millions to dozens, one that ranks the dozens. Confusing them is a common mistake.
Same shape, different products: Typeahead · Product search · Log search. Once you can do one of these, the others are the same five stages with different numbers.
Limits and abuse
Deciding whether to say no, cheaply, on every request.
The tell: The decision has to be faster than the work it protects, which rules out most of the accurate answers.
Same shape, different products: API rate limiter · Distributed counter · Fraud checks. Once you can do one of these, the others are the same five stages with different numbers.
Location
Two dimensions pretending to be one, plus a very high write rate from things that move.
The tell: Writes hugely outnumber reads, positions are stale the moment they land, and the index gives you candidates rather than an answer.
Same shape, different products: Nearby places · Delivery zones · Live location ingestion. Once you can do one of these, the others are the same five stages with different numbers.
Data pipelines
Enormous volume in, aggregates out, and nobody is waiting for any single event.
The tell: Here you can usually afford to be minutes behind. Spend that slack: batch aggressively, and design for replay when a job is wrong.
Same shape, different products: Analytics ingestion · Click aggregation · Metrics. Once you can do one of these, the others are the same five stages with different numbers.
Crawling and ingestion
The work is unbounded, the sources are hostile or fragile, and you are a guest on someone else's machine.
The tell: There is no fixed input size: the queue of work generates more work. So the interesting questions are what you refuse to fetch, how you avoid fetching the same thing twice, and how you avoid hurting the sites you depend on.
Same shape, different products: Web crawler · Feed and API ingestion · Data scraping pipelines. Once you can do one of these, the others are the same five stages with different numbers.
Sync and offline
The same data lives on several devices, all of which can be edited while disconnected.
The tell: Two people (or one person on two devices) changed the same thing offline. Everything hinges on whether you detect that or silently pick a winner, and on how little you can transfer to bring a device up to date.
Same shape, different products: File sync · Offline-first notes · Collaborative editing · Mobile app caches. Once you can do one of these, the others are the same five stages with different numbers.
Building the storage itself
You are not using a database. You are being asked to design one.
The tell: The vocabulary flips from "which store do I pick" to replication, quorums, partition assignment and durability. This is the group where every Tier 2 concept is the answer rather than the context.
Same shape, different products: Distributed key-value store · Distributed cache · Object storage · Message broker. Once you can do one of these, the others are the same five stages with different numbers.
Money and correctness
Being fast is worthless if the number is wrong, and every mistake is somebody's actual money.
The tell: The design is dominated by exactly-once effects, audit trails and reconciliation with a third party who holds the authoritative record. Availability is negotiable here; correctness is not.
Same shape, different products: Payments · Digital wallet · Ledger · Billing and invoicing. Once you can do one of these, the others are the same five stages with different numbers.
Two problems that look the same and are not
Ride hailing
A person is standing on a street. Zero slack. So matching must be greedy and immediate: take a good driver now, not the best driver in forty seconds. Global optimisation is the better algorithm and the wrong product.
Food delivery
The restaurant needs fifteen minutes to cook. That is fifteen minutes of slack to hide latency inside, so you can batch orders, wait for a better courier, and optimise across the whole set.
Ask “where’s the slack?” before you draw anything. It decides sync versus async more than anything else.