Engineering, in the open
Fast and correct is half the job. The other half is failing safely.
Any system can look good at its rated load. We deliberately pushed the platform to twice its comfortable rate and watched whether it failed safely without moving the books.
4M+
requests
Processed while the payment path was held under deliberate overload.
700K+
busy · retry
Excess work rejected immediately with an answer clients can act on.
0
timeouts
Served traffic stayed responsive throughout the run.
0
ledger violations
The independent correctness audit stayed clean.
Two ways to break under load
When more requests arrive than a system can serve, it can keep accepting everything and slowly drown: latency climbs, requests time out, connections pile up, and unhealthy traffic eventually takes healthy traffic down with it.
Or it can recognise that it is at capacity, keep serving what it can quickly, and turn the rest away with a clear try again in a moment.
The first pattern is how outages cascade. The second is graceful degradation. For a payments platform, it is not a nice-to-have—the worst possible time to corrupt a ledger is the exact moment it is busiest.
We pushed to 2× capacity. Nothing broke
We drove the payment path to twice its comfortable rate and held it there. Across more than four million requests under deliberate overload, every request either completed quickly or received a clear, immediate busy, retry shortly response.
More than 700,000 units of excess load were turned away this way instead of being dropped as failures. Nothing hung. Nothing timed out. Served traffic stayed fast for the duration of the run.
A fast rejection is honest capacity management. A slow timeout is an outage in progress.
And the books never moved
Turning traffic away cleanly is good engineering. Keeping the ledger perfectly correct while doing it is the point.
Under full overload, an independent audit recomputed every account balance directly from raw transaction records—without trusting the software’s own bookkeeping—and checked the invariants a correct ledger must always satisfy:
Conservation
Money is neither created nor destroyed; every currency nets to zero.
Every transaction balances
No individual movement leaves the books uneven.
Stored equals recomputed
Every balance matches the sum of its own history.
No overdraft past the floor
No account holds a balance its rules forbid.
Every check returned zero, exactly as it does at rest. A ledger that stays correct only when it is comfortable is not trustworthy. This one stayed correct while the surrounding system was being overwhelmed.
Why we test the bad day
Happy-path benchmarks tell you how a system looks in a brochure. They do not tell you what users experience when a campaign goes viral or payday traffic lands at once.
Those are the moments a payments platform earns or loses trust. They are worth proving out in advance, on purpose, with the results written down.
We are not describing the mechanism that sheds load, because that is our engineering. We are documenting the externally observable behaviour and publishing the evidence so the conclusion does not depend on our word.
The evidence is public
Early access
Become a design partner.
We are working with a small number of teams building wallet and money products on WalletD. If that is you, let's talk. You will get direct access to the people who built it.