systemInPain.com0/15 passed

Choose a level.

Each level is a real system under real traffic. Pass one to unlock the next — the curriculum builds on itself, one concept at a time.

TinyURL

A founder needs a URL shortener. Light traffic, simple job: take a long URL, hand back a short one. Wire up the basics and make it work.

Client–ServerAPIs

Pastebin

Your paste-sharing site went viral on a forum. 90% of traffic is people reading the same popular pastes — and the database is buckling. The budget is too tight to just buy more database; make the reads cheaper instead.

CachingRead-Heavy Workloads

Write Firehose

A telemetry service ingests a flood of events — 300 per second, and 80% of them are writes that must be stored. A read-cache can't help you here (there's nothing to cache), and your SQL database is drowning. Pick a datastore actually built for this write volume.

Datastore SelectionWrite-Heavy Workloads

Flash Sale

An e-commerce store is running a flash sale. Normal traffic is fine — but when the sale drops, demand spikes 5×. Build a system that doesn't fall over the moment everyone shows up at once.

Traffic SpikesHeadroom

Lean Startup

You inherited this system from an engineer who never met a component they didn't like. The load is modest and read-heavy — nowhere near what this stack was built for — and the burn rate is eating the runway. Nothing here is broken; there's just too much of it. Strip it back to the smallest design that still meets the bar.

CostRight-Sizing

Event Pipeline

Your telemetry service ingests 150 events per second, nearly all writes — and every night the batch upload window triples the firehose for ten straight seconds. The database keeps up on average but drowns in the burst, and the backlog wrecks the rest of the hour. Decouple the write path so a burst is absorbed, not fatal.

Async WritesMessage Queues

Service Tiers

Your app grew from a script into a real service. Right now the gateway does everything — routing AND business logic AND database calls — and the team keeps stepping on each other. Split the concerns: let the gateway be the front door and move the application logic into its own tier behind it.

Separation of ConcernsApp Tier

Global Reads

A breaking story goes viral — 30,000 requests per minute, 95% of them reading the same content. The origin server is on its knees. Serve the world at the edge before it ever reaches your data center.

CDNEdge Caching

Viral Scale

A product launch drives 126,000 requests per minute. One API server handles 500 r/s; scaled to the maximum (×4) it reaches 2,000 r/s — still not enough. The only way forward is to break through the single-machine ceiling with a fleet behind a Load Balancer.

Load BalancingHorizontal Scaling

Rush Hour

A regional delivery app is having its best week ever — real growth, not a viral spike, and it needs a front door to fan traffic across a small fleet. It's nowhere near the scale that justifies the premium managed load balancer your last job always reached for. Match the front door to the traffic you actually have.

Load Balancer vs Reverse ProxyCost-Aware Networking

Split the Streams

Your read cache is doing its job on the 90%-read load — but every write is being funneled through it too, and a cache is no place for a write. Wire it the real way: reads served from the cache, writes going straight to the datastore. Run it and watch the two streams separate.

Cache-AsideRead/Write Split

Read Replica

Your billing system is relational for a reason — the finance team will not sign off on a NoSQL migration. But read traffic has outgrown what the primary can vertically scale to, no matter how much you're willing to spend on it. Scale the reads without touching the write path.

Read ReplicationVertical Scaling Ceiling

Always On

Your payments service can't blink. At peak, a hardware fault takes the primary database offline for 20 seconds. Adding more capacity won't save you — a dead database at any size is still dead. Design so a single component failure never takes the whole system down.

RedundancyFailover

Bot Flood

Your ticket-sales site is getting scraped to death: half of all traffic is bots hammering random pages. Your cache can't help — the junk requests never repeat, so every one of them punches through to the database while real customers watch spinners. Stop the flood at the front door, before it touches your origin.

Edge SecurityWAF

Overwhelmed

Bot Flood's attacker is back with a botnet ten times the size. Whatever filtered through last time isn't cutting it — the leaked traffic alone is enough to bury your origin. A rough volumetric shield was fine before; this flood needs tighter inspection at the edge.

WAF vs Rate LimiterDDoS Mitigation