REST vs WebSocket for Odds Data: When Real-Time Actually Matters

REST is pull: your client asks for the current state of a market and gets a snapshot. WebSocket is push: you open a persistent connection, subscribe, and the server sends you each price change as it happens. The same odds can flow over both; the difference is who decides when data moves, you or the event itself.

For odds specifically, this distinction is unusually consequential, because odds are not slowly drifting values. They are step functions that jump when information arrives, a goal, a red card, a lineup, a sharp bet, and the entire economic value of the data is concentrated in the seconds around those jumps.

With polling every T seconds, a price change waits on average T/2 before you see it, and up to T in the worst case. Poll every 10 seconds and your view of the market is on average 5 seconds old at the moment of any change; poll every 60 seconds and you are routinely acting on prices from half a minute ago.

Tightening T runs into arithmetic. Eight bookmakers times a few hundred concurrently interesting markets is thousands of endpoints; at 10-second polling that is hundreds of requests per second, most of which return unchanged data. You pay full infrastructure cost to learn, 95%+ of the time, that nothing happened, while still carrying multi-second staleness on the 5% that matters.

Push inverts the cost structure. A WebSocket delivers exactly one message per actual change, so bandwidth scales with market activity rather than with your paranoia, and staleness collapses from T/2 to network transit. OddStream's stream runs at sub-200ms median latency, roughly a 25 to 300-fold freshness improvement over realistic polling intervals.

Concrete case: a live football match, a goal is scored, and a bookmaker's over/under price is mispriced for eight seconds before its model catches up. With a WebSocket feed you see the stale price within 200ms and have most of that window to act. Polling at 15 seconds, you have a 47% chance of not seeing the window at all, and even when you do, half of it is already spent.

Pre-match, the moves are slower but the pattern holds. Odds shift in bursts when team news drops, typically 60 to 90 minutes before kickoff, and in the final minutes before start. A value bet flagged at 2.10 that has since been cut to 2.02 is not a slightly worse bet; at a devigged fair probability of 50%, it is the difference between +5% EV and +1% EV, most of the edge gone. Systematically arriving late by even 20 seconds shaves points off your average CLV, and average CLV is your long-run ROI.

Not every use case is latency-sensitive, and pretending otherwise wastes engineering effort. Building a morning odds-comparison page, computing daily margin statistics, backfilling a historical database, or running a batch backtest are all pull-shaped problems: you want a consistent snapshot at a time you choose, and REST is the simpler, more debuggable tool.

A useful rule of thumb: if the decision consuming the data happens on a human schedule, hours or days, poll. If the decision is triggered by the data changing, an EV alert, an arb check, a live model, push. REST is also the right recovery path even in real-time systems, which leads to the architecture most production consumers converge on.

Mature odds consumers use both transports deliberately. REST provides the initial state: on startup, fetch a full snapshot of events and markets so you have a complete picture. WebSocket provides the deltas: subscribe and apply each update to the in-memory state. On disconnect, and disconnects will happen, re-fetch the snapshot over REST to resynchronize before resuming the stream, rather than trusting a gap-riddled state.

This snapshot-plus-stream pattern gives you correctness from REST and freshness from WebSocket, and it degrades gracefully: if the socket drops for 30 seconds, you fall back to the accuracy of a polling system instead of failing. OddStream exposes both interfaces over the same data model for exactly this reason; the snapshot you fetch and the deltas you stream describe the same markets with the same identifiers.

Ask one question: what is the cost of acting on a price that is T/2 seconds old? For a stats dashboard the answer is nothing, so poll generously and keep the system simple. For pre-match value betting the answer is measured in lost EV per bet, so stream, and measure your detection-to-alert latency as a first-class metric. For live betting or arbitrage the answer is the whole strategy, and push is not optional.

Whichever transport dominates, instrument staleness explicitly: log the delta between the feed's event timestamp and your processing time, and alert when it drifts. Most real-world losses attributed to a bad model are, on inspection, a good model fed old prices.