The 83rd minute at the 2026 World Cup, round of 16. Argentina are 2-1 down to Egypt and close to going out. The ball bounces around the Egyptian box, falls to Lionel Messi, and he stabs it in left-footed from close range. On the pitch, it is 2-2 and Argentina are alive (spoiler: they win 3-2 two minutes into stoppage time).
In the data layer, one scrappy finish sets off an avalanche.
The scoreline changes. Messi's tally moves to eight goals, putting him top of the Golden Boot race at that moment. It is his 21st goal across all World Cups, a record, and his ninth consecutive World Cup match with a goal. Argentina's win probability is recalculated. Live betting markets are re-priced across dozens of bet types. Fantasy points recompute for millions of teams that hold him. Broadcast graphics and pundit stat packs regenerate. Coaching analytics tools log the sequence for later review.
All of that follows from a single event, and most of it has to be correct within a few seconds, while fans are still refreshing. The post-match batch jobs have not started. They will not help. Batch alone stopped being good enough some time ago, and a late goal in a knockout tie is exactly the moment that proves it.
This is the part the market conversation tends to skip. The slides are about the app: the second screen, the personalised feed, the automated highlight. The engineering reality sits one layer down, in the pipeline that turns one on-pitch event into consistent truth across every system that consumes it, sourced from providers that do not agree with each other. That pipeline is the subject here.
The five consumers behind one goal, and why they don't agree on "fast enough"
The same goal feeds at least five different consumers, and each one has a different tolerance for latency and for error. That difference is not a detail. It is the thing that should shape the architecture and the budget.
- Live scores on a website or app: fans want the number now, especially when stadium networks are congested and the person on the sofa is a second ahead of the person in the ground. A short delay is survivable. A wrong score is embarrassing but recoverable.
- Betting and prediction markets: here, milliseconds carry money. A stale price is an arbitrage opportunity for someone else. A wrongly settled bet is worse than a delay: it means refunds, manual intervention, and exposure to the regulator.
- Fantasy football: points must be correct and, above all, consistent for every player who holds that footballer. An error is visible to millions at once, and fairness is the whole product.
- Professional analysis and pundit commentary: needs rich, accurate context quickly, but can tolerate a few seconds while a graphic is prepared. Depth matters more than raw speed.
- Coaching and backroom analytics: tolerant of latency, often reviewed after the match, but demanding on depth and precision. A misattributed touch or a missed event undermines the whole analysis.
One event, five latency-and-error budgets. You cannot serve all of them from a single pipeline SLA and expect it to hold. The practical consequence is that “real time” is not one target. It is a set of targets, and the cost of missing each one is different. A design that treats the betting feed and the coaching export as the same problem will over-spend on one and under-protect the other.
Turning a live avalanche into real-time truth
The first hard problem is volume and velocity arriving together. A tournament generates a continuous stream of events, and the peaks land exactly when interest is highest and patience is lowest.
Why the 89th minute breaks your API, not your model
Peak load in this domain is brutal and predictable. Kick-off, half-time, a penalty, a late winner: interest spikes, and so does read traffic. Fans in front of the television want the state of the match to update as it changes, with no loading spinner. Fans in congested stadiums are hammering the same endpoints from worse connections.
What gives way first is rarely the clever part. The logic that recalculates statistics, odds and standings after each event is demanding, but it is not usually what fails under load. What fails is the read path: the API serving live match state and the web tier rendering it to millions of screens at once. This is a scalability test for the application and the infrastructure behind it, and it is failed most often by teams who pour their attention into the processing logic and treated the serving layer as plumbing. The 89th minute does not care how clever your pipeline is if the API cannot answer.
Creating a microservice that caters for up to 30,000 events per minute, enabling our client to run metric reports and draw conclusions
Read the case studyMany stores, one truth: the cache-invalidation tax
Live state is rarely held in one place. A typical stack reads from several: a relational database such as PostgreSQL as the authoritative record, a document store such as MongoDB for flexible event and statistics documents, and an in-memory cache such as Redis to serve reads fast enough to survive the peak.
One event has to update all of them, and they have to agree. Keeping them in sync under load is genuinely hard, and cache invalidation is famously one of the two hard problems in computer science. That has not stopped being true here. There is no way to remove the problem entirely, but there are architectural approaches that make it manageable: event-driven propagation, versioned records, disciplined time-to-live policies. The right combination is a topic in its own right. The point for a decision-maker is narrower: your correctness at peak depends on the invalidation strategy far more than on raw compute, and it is worth knowing who owns that strategy before the next tournament, not during it.
When two providers can't agree what a red card is
The proliferation of data stores is one side of the problem. The variety of data sources is the other, and it is where a lot of quiet engineering time disappears.
The second-yellow problem
One provider rarely covers everything. Depth (specific in-game events) and breadth (competitions covered) usually both fall short, so most serious operations take feeds from more than one. Different providers mean different schemas, and the differences are subtle enough to cause real damage.
The classic example is the second yellow card. Is it counted as a yellow card, a red card, or both? All three interpretations have been found running in production across different systems: web, mobile, and API. Reconciling them was not a quick data-cleaning task. It took a months-long debate among domain experts, including a licensed referee, before a single interpretation was agreed and implemented.
Schema mapping across providers is tedious, but it is largely a one-time job. Once built, it holds, until a breaking and sometimes unannounced API change forces a revisit. The lesson for anyone scoping this work is to budget semantic reconciliation as design work, done up front with people who understand the domain, rather than as an afterthought discovered when two screens show different disciplinary records for the same match.
Is this the same Messi? The identity problem that never ends
Schema differences are painful but finite, identity is not. It is the problem that keeps returning for as long as the system runs.
Why provider IDs don't travel
Every data entry reflects a real-world entity: players, coaches, referees, teams, clubs, competitions, tournaments, seasons, rounds. Each provider typically assigns its own numerical ID or UUID, meaningful only inside its own database. Provider A’s identifier for Messi means nothing to Provider B. Multiply that across every entity, every competition, and every season, and add the occasional unannounced API change, and matching the same real-world thing across sources becomes a standing operational cost rather than a one-off mapping.
URIs, registries and a shared language for entities
Part of the answer is a shared format for a global identifier. The W3C’s Uniform Resource Identifier (URI) standard provides one. Unlike a URL, a URI does not need to point to a resource that actually resolves; it is an identifier, not an address. That solves the format problem, but not the registry problem: a format alone does not tell you which URI belongs to which player.
This is where a shared sports ID registry, such as Sports Data Exchange (SDX), does the work. It provides a shared domain for sports, URI semantics for entities, and the canonical URIs themselves, so that Messi resolves to one agreed identifier that every provider’s data can be mapped to. With a stable global ID in place, linking the same player, team, or tournament across providers stops being a per-source guessing game and becomes tractable. It does not remove the mapping effort, but it gives that effort a fixed target instead of a moving one.
Creating a complete system that deduplicated the data of approximately 3.3 million non-profit organisations
Read the case studyWhat it costs, and what actually works today
Two questions follow from all this, and they are the ones a decision-maker actually cares about: what does it cost to keep correct, and how much of it can you rely on today.
On cost, the money does not sit where the slides suggest. Infrastructure spikes with interest: the peak-time scaling that keeps the API up during a late winner is spent in short, sharp bursts, and someone should own that ceiling before kick-off rather than discover it on the invoice. Covering both the depth and the breadth of the data usually means licensing more than one provider, because no single feed does everything. Reconciliation is a standing labour cost: senior domain time, spent once on a hard problem like the second yellow, then again each time a provider changes something.
The sharpest cost is the asymmetric one. A late or slightly wrong live score is cosmetic. A wrongly settled bet or a wrong fantasy score is a financial and regulatory event. This is why the five consumers matter when the budget is set: money and risk should follow the ones with the lowest tolerance for error, not be spread evenly as though a delayed graphic and a mis-settled market were the same kind of failure.
On maturity, it is worth being honest about the line. Distributing live scores at high concurrency, fanning a single event out to many consumers, mapping IDs across providers once that work is done, and serving reads from several stores through a sound invalidation strategy are understood problems today. Real-time re-pricing and fantasy recomputation are achievable too, provided the latency-and-error budgets are set per consumer and enforced. What is still early is fully automated, pundit-grade narrative in real time, and zero-touch identity resolution with no human curation: both are moving quickly, but both still need a person in the loop for the cases that matter. Better to say that plainly than to put them on the same slide as the live score feed.
Build sports data platforms that hold up on match day
From real-time ingestion at peak load to reconciling feeds from multiple providers and resolving player and team identities across them, we build the pipelines that keep scores, markets and analytics correct while the match is live.
We support broadcasters, streaming platforms, and sports data and betting providers in turning tournament data into products fans can trust.
Strategic takeaway
The decision actually on the table is identity. You can build your own mapping and registry layer, buy into a shared registry such as SDX, or partner for it. The reason this is the decision that repays attention is that identity is the problem that compounds across a season and across providers, where schema mapping is largely settled once and left alone. Get identity right and the rest of the pipeline has a stable foundation to sit on. Get it wrong and every new provider, competition, or season adds to a reconciliation burden that never quite goes away.
The wider point reaches past football. The pattern here, one event, many consumers, several sources that disagree, all reconciled and fanned out in near-real time, is not specific to sport. It is the same shape as election-night results, live financial markets, and real-time retail. Getting the identity and real-time foundations right for a World Cup is, in effect, a test of whether the architecture survives the next high-stakes, high-fan-out event of any kind.
That is the work we take on with clients: not the demo that clips one highlight cleanly, but the pipeline that stays correct for every match, every market, and every consumer, across a full tournament and the ones after it. If that is the problem in front of you, it is worth having the identity conversation before the next tournament starts, not during it.
