# breakscale's headline example shows goodput at zero while the database is 99.9% busy

> A canvas where you wire load balancers, caches and databases into a system and drag the traffic up until something fails, with a discrete-event engine underneath and three delivery surfaces: a website, a VS Code panel and a hosted server an assistant can call. The example in the header is the argument in four numbers.

**xevrion/breakscale** — Build a system, load it until it breaks, and watch why. A system design simulator for learning distributed systems.

- Repository: https://github.com/xevrion/breakscale
- Website: https://breakscale.tech
- Stars: 1,239 · Forks: 118
- Language: TypeScript
- License: MIT
- Published: 2026-09-18 · Updated: 2026-09-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/xevrion-breakscale

## The header example is four numbers and an explanation

Under the sponsor block there is one example described in four figures. At one hundred requests a second, the database is 99.9 percent busy and goodput is zero. The reason is stated rather than left to be inferred: retries have turned a hundred offered requests into three hundred and forty-eight hitting a database that was already full. Every request the database does finish has been abandoned by a caller that stopped waiting. That is the whole thesis of the project in one paragraph, because it is the failure mode most diagrams do not show. The rationale section makes the same case from the other side, naming the two intuitions the tool exists to build: why p99 latency falls off a cliff once utilisation passes eighty percent, and how a short timeout with a couple of retries turns one slow database into a total outage.

## The engine claims that no formula stands in for the simulation

The feature list is specific about the mechanism, which is what separates this from a diagram tool. It is described as a real discrete-event engine with finite server slots, service times drawn from a distribution, and percentiles measured from the simulated requests rather than computed afterwards. The claim in the bullet is that no formula stands in for the simulation. Below that, the determinism guarantee: the same seed and the same topology replay identically, every time. That is the property that makes the tool usable for argument rather than for demonstration, because two people can run the same configuration and compare notes instead of comparing screenshots. It is also why the chaos controls are worth having: you can crash a node, slow one down, force an error rate or cut a single link, and the failure travels in a way you can replay after the fact.

## Thirty-three components and twenty-three examples, split sixteen and seven

The palette is counted in the text, not just listed. It opens with four components, a load balancer, a cache, a database and a queue, and then says twenty-nine others, for thirty-three in total. The rest of the list is what a distributed system actually needs and a diagram usually omits: rate limiters, circuit breakers, read replicas, shards, autoscalers, stream brokers, WebSocket gateways, serverless functions and bulkheads. The examples are counted separately and split into two kinds, sixteen teaching scenarios and seven reconstructions of real architectures. The distinction matters for how you use it: a teaching scenario isolates one failure mode, so you can change one thing and see one consequence, while a reconstruction is a system you can take apart to find out why it behaves the way it does.

## Shared designs are encrypted and the key hides in the link

The sharing story is the cleverest mechanic in the project and it is described in one sentence. A design stays in your browser unless you share it. When you do share it, the design is encrypted before it leaves, and the key is kept in the part of the link that browsers never send to a server. That part is the fragment after the hash, which by specification never reaches a host, so the server hosting a shared design sees ciphertext and cannot read the design. It also means there is no account, no server-side key store and nothing to lose but the link itself: lose the fragment and the design is unreadable. The other path is a file. A saved design can be exported as a file with its own extension that opens both on the website and in the editor, and designs saved in the editor live in the editor's own storage.

## Analytics are on the website and off everywhere else

The privacy claim is stated with its exceptions rather than as a blanket promise. There is no account, and designs never leave your machine unless you share them. The website counts page views using the hosting platform's cookie-free analytics. And then the sentence that makes the claim concrete: the editor extension and the server for assistants have no analytics at all. So there is one surface that measures traffic and two that do not, which is a defensible arrangement rather than a contradiction, but it is worth knowing which one you are on if you are modelling a design. Every metric and unit also carries a plain-language definition one hover away, which is a small design decision that does more for comprehension than any amount of documentation.

## The assistant surface is a hosted server, and the local one needs Node 20

Three surfaces, and the third is the most interesting. There is a server for the model context protocol, hosted at its own address, so there is nothing to install; two commands are given, one for a terminal assistant and one for the editor, both pointing at the same hosted endpoint:

```bash
# Claude Code
claude mcp add --transport http --scope user breakscale https://mcp.breakscale.tech/mcp

# VS Code
code --add-mcp '{"name":"breakscale","type":"http","url":"https://mcp.breakscale.tech/mcp"}'
``` If you would rather run it yourself, the same server starts locally through the package runner with a standard-input transport and asks for Node 20. In assistants that support the richer extension of that protocol, the design does not come back as a link alone: it opens as a live canvas inside the chat, and edits you make there flow back to the assistant so its next change starts from what you are looking at. The suggested prompts are good, and one of them is the most honest: read this repository, turn its architecture into a design, and tell me which numbers you guessed.

## A private zero-one build with no releases feeds three live surfaces

The manifest says the package is private and sits at version zero point one, and there are no tagged releases on the code host, so the published version is the only version marker anyone can see. Meanwhile the website is live, the editor extension is in a marketplace listing and the protocol server is running at its own address. That is a deliberate choice about what gets versioned rather than an accident, and it does mean the three surfaces a user touches are not pinned to anything you can inspect. Two smaller signals: a to-do file sits at the root of a repository whose readme reads as marketing, and the local development script backgrounds a worker process and then kills the entire process group when the dev server exits, which is a compact trick that works until it does not.

## Conclusion

Use breakscale if you learn systems by changing things and watching what happens, because the pitch is that the numbers come from simulated requests rather than from a diagram that looks convincing. Three things to know before you plan around it. The whole simulation is deterministic, so results are reproducible and you can point at a specific seed when you disagree with someone. Designs are local by default and only leave your browser when you share one, and the shared form is encrypted with the key hidden in the link fragment, which is a neat trick worth understanding before you rely on it. And the published version is a private zero-one build with no tagged releases, while the extension and the hosted endpoint are already live, so you are depending on a deployment rather than a release.

## FAQ

### What does breakscale simulate?

A discrete-event engine with finite server slots and distributed service times, where latency percentiles and queue depths are measured from the individual simulated requests rather than from a formula. The same seed and topology replay identically.

### How are shared breakscale designs protected?

A design stays in your browser unless you share it, and a shared design is encrypted before it leaves, with the key kept in the part of the link that browsers never send to a server. There is no account involved.

### How do I use breakscale with an AI assistant?

It is a model context protocol server hosted at its own address, so there is nothing to install, and two commands are given for a terminal assistant and the editor. Running it locally instead needs Node 20 and the standard-input transport.

### How many components and examples does breakscale have?

Thirty-three components, and twenty-three worked examples split into sixteen teaching scenarios that each isolate one failure mode and seven reconstructions of real architectures.

### Does breakscale track usage?

The website counts page views with the hosting platform's cookie-free analytics. The editor extension and the protocol server have no analytics at all, and there is no account anywhere.

### Can I move a design between the breakscale website and the editor?

Yes, through a share link or through a design file with its own extension that opens on both. Designs saved in the editor live in the editor's own storage.

## Sources

- [Issues](https://github.com/xevrion/breakscale/issues)
- [License: MIT](https://github.com/xevrion/breakscale/blob/main/LICENSE)
- [Project website](https://breakscale.tech)
- [README](https://github.com/xevrion/breakscale/blob/main/README.md)
- [xevrion/breakscale on GitHub](https://github.com/xevrion/breakscale)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xevrion-breakscale