The challenge
The operator ran two channels with genuinely different characteristics on one platform.
Online brought the familiar demands: payment provider integrations, third-party casino content, and a web product that had to stay responsive under fixture-time load. Retail brought a 200-terminal estate spread across sites with variable connectivity, where the failure mode is not an error page but a queue in a shop and a cashier who cannot serve.
Both channels shared the same betting engine, the same wallet and the same settlement. That is the right architecture, since a customer’s balance should not depend on which channel they used, but it means the load profiles combine rather than average out, and the strictest requirement of either channel becomes the requirement for both.
Approach
Optimisation focused on the write path. Bet placement is a write under contention: validating stake against limits, checking liability, and committing the bet while the same markets are being repriced. Concentrating on that path rather than on the read-heavy parts of the system produced the 40% improvement in bet processing time against the previous baseline.
Terminals were treated as unreliable clients. Any terminal may retry, duplicate a request, or reconnect having missed messages. Each is handled as normal operation rather than as an error, and bet submission is idempotent, so a terminal retrying after a timeout cannot place the same bet twice.
Payment providers were built as adapters, not assumptions. Multiple providers were integrated behind a common interface, so that routing, retry and fallback behaviour lives in one place rather than being reimplemented per provider. Each provider has its own model, its own failure behaviour, and its own idea of what a settled transaction is. Normalising that at the integration boundary is what keeps provider-specific quirks out of the wallet logic, and what makes adding the next provider an adapter rather than a project.
Casino aggregators were integrated against a shared wallet. Third-party casino content arrives through aggregators, each exposing its own session, betting and settlement semantics. The requirement that makes this non-trivial is a single balance: a customer moving between sportsbook and casino sees one wallet, so aggregator transactions have to settle against the same ledger as bets, with the same exactly-once guarantees, despite arriving through an external system on its own schedule.
Availability was designed around the fixture calendar. Load is spiky but not unpredictable, because the fixture list says exactly when demand arrives. Capacity and deployment windows follow it, so changes never land near kick-off and headroom is in place before it is needed rather than in response to it.
Settlement kept its own audit trail. Result feeds duplicate, correct and reorder. Settlement is keyed so that reprocessing the same result cannot pay out twice, and corrections are recorded as reversals rather than overwrites, leaving a full history behind every balance movement, across sportsbook and casino alike.
Results
The platform serves both channels at over 60,000 transactions per day across 200+ connected terminals, sustaining 99.9%+ availability with 40% faster bet processing than the system it replaced.
The availability figure is the one that matters commercially, and it matters differently per channel. Online, downtime is lost turnover concentrated in the hours when the most bets would have been placed. In retail, it is shop-hours where staff cannot take bets at all, and by the nature of the load profile, those hours are the busiest ones.