Problems
Store and retrieve small values by key. Read-heavy, with a durable write path. The simplest problem that makes you reason about both caching and durability.
Share snippets of text via a link. Modest traffic, forgiving latency, data that fits on one database — the problem that grades whether you can resist over-building.
Count page views for millions of pages. Fifty writes for every read, and no cache can absorb a write — the problem that makes you size the ingest path honestly.
Suggest completions on every keystroke with a 12ms budget. The database physically cannot answer that fast — this is the problem that forces an absorbing layer.
Every API call asks you first: may this proceed? The check is a write, the p99 budget is 8ms, and the contract quietly makes exactly one shape of answer fast enough.
Trivial traffic, data that fits on a phone — and a kill switch that must never unflip. The problem where the contract sizes the system, not the load.
Track who's online right now. The data dies in sixty seconds and rebuilds itself from heartbeats — the first contract where a single copy is the right answer, and the trap is deciding you don't need a database at all.
Turn long URLs into short codes and serve the redirects. Reads outnumber writes 100:1 behind a viral hot set — the problem that makes you earn the edge cache and pay for permanent storage.
Upload once, view a billion times. Petabytes of blobs behind a hot set no RAM tier can hold — the problem where the edge does the serving and the database is the wrong tool.
Serve product pages for a storefront under a sale-day flood. The cache is the design — and it only works if you actually size its RAM against the working set.
Authenticate every page load against a session token. The first strong-consistency contract in the catalog: a logout must be visible on the very next read — no TTL is legal.
Millions of players reload the same top-100 pages while scores pour in underneath. A cache erases the read storm in one stroke — and the quiet number behind it is what actually sizes the fleet.
Serve one ranked front page to a hundred-and-thirty-thousand-a-second morning rush. It looks exactly like a feed problem — until you notice that nobody's page is different.
Every driver pings a position every 30 seconds; every rider asks who's nearby. Two heavy streams over one ephemeral dataset — and a cache that can only ever touch 40% of one of them.
Move money under the strictest contract in the catalog — zero staleness, zero loss, quorum everything — at a load that barely fills one database. The grade here is discipline, not scale.
Sell reserved seats through a flash on-sale: a 12× read spike, a seat map that may be at most one second stale, and holds that must never sell the same seat twice. The problem where the cache can't save you.
Serve a personalized home feed to millions. Every feed is different, so 0% of reads are cacheable — the problem where the database tier has to carry the whole flood itself.
Persist every message of a global chat app. Twenty thousand quorum-acked writes a second inside a 100ms budget — the problem where the write path is the whole design.
Sixty thousand metric batches per second, around the clock. The write floor sets your shard count, the relaxed loss window is worth real money, and correctness at this scale has a price tag.
A petabyte catalog behind an edge that eats 95% of a premiere-night flood. The CDN is table stakes — the engineering is the 5% that leaks through, and the origin fleet it lands on.
Twenty thousand pages a second, none of it cacheable, in front of a twenty-billion-URL seen-set that is disk-heavy and write-hot at once. The one problem where the app tier is the product, not the glue.
Authorize 350,000 API calls a second, then prove you still can with a third of every tier gone. The problem where 'handles peak' and 'survives an AZ loss' are different sums — and the grader runs both.