Caching can help sportsbooks handle traffic spikes during major live events, but serving outdated odds can create financial exposure and undermine player trust. Noel Penzer, General Manager and SVP EMEA at Fastly, tells iGaming Expert how event-driven cache invalidation can keep live betting data accurate while reducing pressure on origin servers.
Ask an operator’s engineering team what caching is for and you’ll get a one-word answer: speed. Ask whether they cache live odds and the answer… gets a lot longer.
That hesitation makes sense. Across most of an operator’s stack, a stale response is a minor annoyance. An old banner or a product image that hasn’t refreshed costs nobody money. Odds, in-play bets, and live scores are different. A stale price isn’t just slow, it’s wrong.
A few seconds is a long time
A striker scores in the 87th minute. Your pricing engine knows within moments: the market suspends and the odds are repriced – your cache doesn’t. For the next few seconds, the two disagree, and the player sees the cached version. For that window, your platform is quoting a price your trading team has already pulled.
This is a hypothetical, but anyone who has run live betting will know the shape of it. You end up with exposure on bets at outdated prices, bets that get voided, customers who feel cheated, and a support queue that fills up after the final whistle. None of it shows on a latency dashboard, because as far as the dashboard can tell, everything was fast.
Why Neither fix works
Most teams pick one of two approaches.
The first is to skip caching for live data entirely, so every request goes to origin, the servers where your pricing data actually lives. You get correct data and a lot of load, and the load arrives at the worst possible moment: the biggest match of the year, with every player refreshing at once. You’ve protected the data but put the platform at risk.
The second is a very short time-to-live (TTL), a timer that tells the cache how long it can keep a copy. Set it to a second or two and hope for the best. It trims the load but doesn’t fix the problem, because the TTL knows nothing about the goal. It expires on its own schedule, not the match’s. You still serve stale prices inside the window, and origin still gets a steady drip of revalidation traffic.
Both treat freshness as something you tune with a timer. The most useful question is who decides when something is stale.
Who decides when odds are stale
The system that knows the price should decide. Leave content in cache for as long as it’s valid and clear it the moment it isn’t. In practice, that means pairing a long TTL, which keeps traffic to origin low, with a purge whenever the content changes, so players always see current prices.
Three pieces make it work:
- Surrogate keys: A label you attach to cached content so you can clear it as a group. Tag responses with the identifiers that matter to you, like a match, market, or league. One purge for a key clears every cached object carrying it, without you needing to know which URLs those are. Tagging at the level of the match or market, rather than every price change, will also help keep your purge volume manageable.
- Event-driven invalidation: Your odds feed or trading system fires the purge when a market changes. No timer involved.
- Purge by key, not purge-all: A targeted purge removes only what has changed so the rest of your cache keeps doing its job. Purging everything clears content that’s still good and sends a rush of traffic back to origin, which is the last thing you want mid-match.
Speed matters here because invalidation only protects data integrity if it finishes before the damage does. With Fastly, a purge by surrogate key or URL reaches every cache server in the network in around 150 milliseconds. That’s a much tighter window than waiting for a TTL to run out.
This approach is for data every player sees, such as odds, scores, and market status. Bet slips, balances, and anything personal to a player should stay out of shared cache.
Freshness comes down to control
Everything above comes down to who decides when cached data has expired. A TTL hands that job to a timer. Tagging content and purging on events hands it to your trading platform, which is the one system that actually knows when a market has moved.
The same approach applies to anything that changes faster than a release cycle. Cached responses can also carry decisions about which markets and promotions are available where, and with rules shifting by state and by country, those decisions go out of date quickly. If cached content is tagged by jurisdiction as well as by match and market, a rule change becomes a purge rather than a deployment.
Live data can stay in cache, which keeps pressure off origin during the biggest matches, and the decision about what counts as current stays with the systems that set the price.
