Move the traffic and watch the boxes change their minds. These are the same verdicts the practice canvas gives you.
Peak requests per second · 100 ms latency budget
1k/s
1k reads/s
App server
Right-sized1k/s of 2k/s — 51% used.
Redis cache
Over-builtAt 1k/s Postgres isn't busy, so it answers redirects well within 100ms on its own.
Postgres
Right-sized2% used, but one instance is already the smallest setup. Nothing to shrink.
Traffic, read/write ratio, latency, durability. They set the load, not a slider you pick at random.
Drag in components and wire them up. There's no reference diagram to copy from.
Right-sized, over-built, or breaking, each with a one-line reason. Change the scale and guess what flips first.
Design Bitlyeasy
Users shorten long URLs and get a short link; anyone with the link is redirected. ~10M DAU, reads dwarf writes.
Design Pastebineasy
Users paste a block of text and get a short link to share it; anyone with the link can read it. Reads outnumber writes about 10 to 1.
Design a Rate Limitermedium
Cap how many requests each client can make to your API, say 100 a minute, and reject the rest. Every single request has to be counted.
Design an Ad Click Aggregatormedium
Users click ads and land on the advertiser's site. Every click is recorded, and advertisers see clicks per ad per minute. Clicks are billed, so a lost click is lost money.
Design Dropboxmedium
Users upload files from any device, download them anywhere, and see changes sync to their other devices. Files can be up to 50 GB.
People learning system design memorize reference architectures instead of working them out. They over-build by default, like Kafka with no async work to do or sharding at 10k users, or under-build without noticing, like one small database at 10k reads/s. Nothing tells them while they're designing. Litmus does.
Pick a problem