Two requests, one balance, a window of microseconds. When the balance check and the debit are not atomic, money leaves twice.
A withdrawal is a read-then-write: check the balance, then debit it. If those two steps are separate and the request is fast enough, two parallel requests both read the same balance before either debits. Both are approved, and the account goes negative — or a float account pays twice.
On a crypto exchange or a casino cashout this is direct money loss, and it is only visible when someone deliberately fires the same withdrawal in parallel. Normal testing never does that.
Withdrawal, cashout, redeem, refund, bonus claim — any flow that moves value in a read-then-write pattern. Exchanges and casinos are the most exposed because the flows are public and the incentive to try is high.
We fire the same withdrawal with HTTP/2 single-packet parallelism and show both requests approved against one balance — with a negative control that a normal serial withdrawal is rejected correctly.
No. Tests run on isolated fixtures and test accounts, never on customer balances.