A capacity-planning tool that teaches
Design it.
Break it.
Fix it.
before production does.
Draw a system, give it traffic, and see what breaks first — at what load, what it does to latency, and what it costs to fix. Every number shows its working.
A payment platform at 7.5K checkouts a second. Five components give out; the engine says which, and why.
- 8
- worked problems
- 24
- concepts, each with a widget
- 18
- component types, plus your own
How it works
Draw it. Give it traffic. Push it. Read the answer.
Draw the system you are actually building. Components come with real capacities — a service, a cache, a database with replicas, a third party with a rate limit — and every line between them is a declared call, not a guess.
What makes it different
Not a drawing tool with numbers on it. A model you can argue with.
- Declared, not guessed
- You state how traffic splits, fans out and routes. The tool never infers what your load balancer does — it asks, then shows the arithmetic per component so you can check it.
- Time, not just steady state
- Run a spike through the design with a real autoscaling policy and see the window where new copies are not there yet.
- Honest about its limits
- Latency is a textbook approximation and says so. Failure modes cover what the model can express and name what it cannot. Defaults are flagged until you replace them.
Start here
Start with a problem.
Three systems to build, stress, and understand.
- 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.
Learn the ideas
The concepts behind the systems.
Short explanations. Real trade-offs. Click to go deeper.
- CachingEvery write strategy trades durability against how often you touch the store.Data→
- Retries, Backoff and JitterEvery retry adds load to the thing that just failed. Backoff and jitter trade a little extra latency for not making the failure worse.Traffic→
- ConsensusA majority quorum survives minority failures and never splits, at the cost of a round trip to most of the cluster on every decision.Consistency→
The bottleneck is already in your design.
Find it on a Tuesday, not at launch.
7 templates to start from, or a blank canvas. No account, nothing uploaded — your designs stay in your browser.