Auditable architecture · Unit 12 of 13
Experiments reveal, they don't confirm
An admission gate can have its logic unit-tested —reject over the limit, release the slot, respect priority— and still fail for three reasons no unit test can see. An occupancy counter with a safety TTL resets mid-flight if load is sustained longer than the TTL, and over-admits: it only shows up past that time threshold, never in a short run. A gate placed after the first database query protects nothing: the load already touched the resource before the gate weighs in. And in a shared-nothing model, opening a connection per request exhausts the ephemeral ports at enough throughput. All three are invisible to the logic test and to the sub-30s benchmark; all three become obvious under real, sustained load.
By the end, you'll be able to
- Recognize why a capacity machine with green unit tests can still fail under sustained load.
- Design validation to reveal the behavior the hypothesis doesn't explain, not to confirm it.
Understand
An admission gate can have its logic unit-tested —reject over the limit, release the slot, respect priority— and still fail for three reasons no unit test can see. An occupancy counter with a safety TTL resets mid-flight if load is sustained longer than the TTL, and over-admits: it only shows up past that time threshold, never in a short run. A gate placed after the first database query protects nothing: the load already touched the resource before the gate weighs in. And in a shared-nothing model, opening a connection per request exhausts the ephemeral ports at enough throughput. All three are invisible to the logic test and to the sub-30s benchmark; all three become obvious under real, sustained load.
The lesson isn't 'write more tests'; it's what an experiment is for. It doesn't exist to CONFIRM the hypothesis —'the machine works, the benchmark proves it'— but to REVEAL the behavior the hypothesis doesn't yet explain. The most valuable validation tool is the one able to observe a phenomenon the rest of the tests can't: the unit test measures logic; the sustained benchmark measures what emerges from time, concurrency and real connections. When the result refutes the comfortable hypothesis, that is the value, not the failure. Hence the evidence discipline: 'done' isn't a claim, it's an artifact reproducible under the conditions where the system actually runs —sustaining load beyond any TTL, measuring where the queue forms, counting the real connections.
See
Open the runtime x-ray
The x-ray shows that each path of an operation leaves a distinct trace —the same discipline of looking at real behavior, step by step, that a sustained benchmark applies to capacity.
Do
Run the practice in your checkout and keep the output as evidence.
Verify
Show that you can apply the unit. Progress only advances once you pass the assessment.
Criteria assessed
- Give an example of a capacity defect a unit test with green logic can't exhibit, and say which benchmark condition reveals it.
- Explain the difference between an experiment that confirms the hypothesis and one that reveals what the hypothesis doesn't explain.
Primary sources
- k6 — load testing
- Runtime x-ray (Academy)
Content verified: 2026-07-23