In most software, a bug gets reported, prioritised and fixed next sprint. In real-time betting, a two-second bug can mean an incorrect settlement on real money, live, while the event is still running.
The difference is not complexity, it is the window
A streaming system can degrade gracefully: resolution drops, the viewer waits a moment. A real-time betting system has no such luxury. If the odds feed lags the actual event by 400ms, the arbitrage window is already open and somebody will take it.
- Latency is not a performance metric, it is a financial risk surface.
- A rollback is not “revert the code”, it is reconstructing the state of every open bet in that window.
- Compliance is not audited at the end of the sprint, it is audited transaction by transaction.
What actually has to be tested
The test that matters is not that the endpoint responds. It is that the customer’s balance, the house’s and the regulator’s all agree after any sequence of events — including the ones that fail halfway:
// This is not enough
expect(response.status).toBe(200);
// This is what actually has to hold
expect(await getLedgerBalance(betId)).toEqual(expectedSettlement);
expect(await getAuditTrail(betId)).toBeConsistentAcrossRetries();Why this defines the team, not just the code
A squad working on these systems needs to understand the regulation as well as the code: what may be retried, what must be frozen, and what requires full traceability before it touches production. It is senior engineering not because of the language or the framework, but because of the cost of being wrong.
Zero tolerance for failure is not a marketing line. It is a design constraint that changes how every line gets written.