Breakscale: load it until it breaks
Build the load, not the diagram. Twenty-three worked systems, a slider that raises traffic until something gives, and chaos controls that break a component mid-run — with every number coming out of a real discrete-event simulation rather than a rule of thumb.
Whose model this is
Breakscale is a system design simulator written by xevrion and released under the MIT licence. It is not part of this project. Its simulation engine — and nothing else of it — has been copied into this repository at a pinned commit so that the runs on this page happen in your browser, in code that ships with the site and is covered by its tests. The full editor, where you can draw your own topology instead of loading one of the twenty-three below, is at breakscale.tech.
What it stands behind: the queueing. Finite server slots, real FIFO queues, service times drawn from a gamma distribution so that variance produces a tail, work that keeps burning capacity after the caller has abandoned it, and percentiles measured off completed requests rather than assumed. What it does not stand behind: any particular millisecond. These are simulated numbers on simulated hardware — what transfers is the shape of the curve, never its absolute height.
How to read it
- Pick an example and leave the load where it is. This is the system working, and it is the only state in which its latency numbers mean what they look like they mean.
- Raise the load one step at a time and watch which reading moves first. It is the tail, always, and it moves while throughput still looks perfect — that gap is the window in which you still have choices.
- Open Load curve. Twelve runs at twelve loads, and the point where the served line leaves the diagonal is this design’s capacity — measured, not estimated.
- Then break something. A crash is the easy fault; slowing a component down is the one that teaches, because nothing reports a failure and the system keeps accepting work it can no longer finish.
- Finally open One request. The split between waiting and working is the question a percentile refuses to answer, and the two halves have opposite fixes.
One service in front of one database. Latency climbs sharply as the database fills up.
Where this sits next to the rest of the Atlas
The Performance Lab answers the same family of questions with different machinery: it solves a queueing approximation in closed form, so it is instantaneous and lets you sweep a parameter continuously, at the cost of being exact about an idealisation. This page moves individual requests through a topology, which is slower and reproduces things no closed form has — a retry storm feeding itself, abandoned work still holding a server slot, one shard melting while the average stays healthy. Reach for the approximation to reason about a single tier, and for the simulation when the interesting behaviour is what the tiers do to each other.
Three of these scenarios are embedded in the lessons that argue from them: load shedding, retry amplification and crashed or just slow. The rest of the domain’s interactives — which run this repository’s own models, not this one — are in the lab.