xevrion/breakscale

Hey @xevrion awesome project. Just had a small query:-

Can you somehow add a way for us to write code (or maybe pseudo-code) inside servers or dbs to understand how does one's code scales or survives under different condition?

This is a good request and it is not something the app does today, you are right that you looked and it is not hiding somewhere.

Two thirds of it already exists though, just not joined up. Every component has a headroom readout in the inspector, ceiling divided by what is actually arriving, and below 1.0x that node is the thing that cannot keep up. So finding the bottleneck is solved; what is missing is saying what to do about it.

The bit I would want to be careful about is offering several fixes with tradeoffs. One of the challenges in the app exists specifically because the obvious fix, making the database bigger, does not work there, and a suggestion that sounds reasonable and makes things worse is worse than saying nothing. So I would rather start with one suggestion for the worst-off component, tied to what that kind actually does, and only get clever later if it earns it.

Two more ideas came up while building the first version, worth writing down before they get lost.

**Briefs that start from a blank canvas.** The four in this first pass all start from a preset that is already failing, so the task is "work out why this breaks and fix it". That is deliberately the easier half. The original framing was "design and deploy a system under these requirements", which means starting from nothing, and that is a genuinely different and harder exercise. Worth having as a second kind rather than a replacement: diagnosing a broken system and designing one from scratch teach different things, and the first is a much gentler place to start.

**Submitting a passed challenge, the way an assignment is handed in.** I would not build this as it sounds. Submissions imply accounts, a backend, and somewhere to store student work, which is an LMS rather than a simulator, and "everything runs in your browser, nothing leaves the page" is worth more than the feature.

The need u...

A budget ceiling came up, and it is a better idea than I first credited:

> some mechanism for a budget? maybe not like the real prices of a cloud provider but some kind of in-game currency to not just "hey autoscale to hell" so the challenges have a ceiling

I went to check how bad the no-ceiling version actually is, on the same `retry-storm` brief as above, and it is worse than "the answer is boring":

```
cap=8 inst=1 p99=121ms errors=0.0%
cap=16 inst=4 p99=120ms errors=0.0%
```

Eight times the hardware. One millisecond better. The database stopped being the bottleneck somewhere before that and the rest is spent on nothing.

So a challenge with no ceiling does not merely have a dull answer, it teaches a false one. A student who scales until it passes concludes that more hardware fixes things, which is the opposite of what every example here exists to show. The ceiling is what forces the actual lesson: find the thing that is actually limiting you, rather than paying to avoi...

Worth saying before anyone starts: this does not have to be big, and I would rather it were not on the first pass.

The expensive part of "add lots of challenges" is authoring scenarios, and there are already 23 of those. Each one has a topology and a description of the failure it teaches. A challenge on top of an existing preset is a brief in words plus a condition the engine checks, so most of the work is done.

I prototyped the whole thing against `retry-storm` to see whether it is actually fun before committing to a design. Brief: hold 150 rps with p99 under 200ms and errors under 1%. The only thing the student changes is the database capacity.

```
db capacity 4 p99= 0ms errors= 99.3% fail
db capacity 6 p99= 0ms errors= 97.8% fail
db capacity 8 p99= 121ms errors= 0.0% PASS
db capacity 10 p99= 89ms errors= 0.0% PASS
```

Two things that came out of that and I think should shape the design.

The interesting part is the cliff between 6 and 8, not the passing...