Betting during an event is the most demanding part of a sportsbook from a technical standpoint. Prices here are recalculated continuously, and the decision to accept a bet is taken in fractions of a second. The hard part is not the interface: the operator always sees the event with a delay relative to what has already happened at the venue.
The data chain and its delays
Several links sit between what happens on the pitch and the player's screen: capture of the event on site, transmission into the data supplier's system, normalisation, recalculation of prices by the trading platform, delivery to the client. Each link adds its own delay, and the total gap is the sum of them all. The stream is a separate problem: it usually runs with a lag of its own that does not match the data delay.
How the operator compensates for the gap
The delay cannot be removed entirely, so the exposure is contained by procedure:
- bet acceptance delay — a stake is confirmed after a short pause rather than instantly;
- market suspension during dangerous passages of play and on loss of signal;
- source reconciliation — a discrepancy between feeds blocks trading on the event;
- reduced limits on markets where the price moves fastest.
What that demands of the platform
Load is distributed extremely unevenly: request spikes land on the key moments of a match, exactly when the whole market tree is being repriced. Bet placement has to be idempotent, otherwise a resend on a dropped mobile connection creates a duplicate; and a rejection has to return an intelligible reason rather than a generic error.
The quality of a live offering is therefore defined by engineering characteristics — feed resilience and predictable latency — rather than by the breadth of the market list.