104 Matches, 40 Broadcaster Architectures: Personalisation Is a Pipeline Problem

The delivery numbers from this World Cup are impressive on their own — 104 matches, over 54 countries, 40 different broadcaster architectures, every match in full UHD for the first time in the tournament’s history, peaking at 117 Tbps.

But the number that reveals the actual engineering challenge is 40 broadcaster architectures. Not one pipeline. Forty consumers, each with its own encoding requirements, packaging preferences, DRM, ad insertion, language tracks, graphics conventions and delivery endpoints — all fed from the same source events, in real time, without a maintenance window for five weeks.

That is a fan-out problem, and it is the same problem sitting under every “personalised content” initiative I have reviewed, in media and well outside it.

Personalisation is not a recommendation model#

The industry conversation about personalised media focuses almost entirely on the selection layer — which highlight to show, which clip to surface, which model ranks them. That is the easy part and it has been solved adequately for years.

The hard parts are upstream and downstream of it.

Upstream: you need metadata dense enough to select against. A highlight reel personalised to a specific player requires knowing which seconds of which match contain that player doing something notable. That is a structured event stream aligned to video timecode, with entities resolved to a canonical identifier, and it is produced by a combination of computer vision, sensor data, and — as the tournament’s own analytics pipeline shows — a substantial layer of human annotation tagging up to 3,000 actions per match.

If that metadata is thin, wrong, or misaligned by two seconds, no ranking model rescues the output. You will produce a clip that cuts before the goal.

Downstream: you need to render and deliver the variant. Selecting a personalised sequence is cheap. Actually producing it — cutting, transcoding into a full bitrate ladder, packaging for multiple DRM systems, and delivering it — is expensive and it multiplies. One personalised variant per user is computationally impossible at scale. This is why almost every real system personalises the playlist, not the pixels: pre-render a library of segments once, and personalise the assembly order and the manifest.

That distinction is the single most important architectural decision in the space, and teams that get it wrong discover their transcoding bill scales linearly with users.

The timecode is the join key#

Everything in this domain reduces to one thing: can you reliably align an event to a frame?

If your event stream says a goal occurred at 67:14 and your video timecode says something two seconds different, every automated clip is wrong. Not subtly wrong — wrong in the way that makes the product unusable, because the interesting moment is exactly what got cut.

Alignment across a distributed production is genuinely hard. Cameras, replay servers, graphics systems, sensor feeds and encoders all have clocks, and those clocks drift. Broadcast has a proper answer to this — PTP timing, genlock, SMPTE timecode embedded in the signal — and organisations coming from a software background frequently underestimate how much rigour is required, having never had to synchronise anything to a frame before.

The general lesson transfers beyond media, and it is the same one the connected match ball illustrates: when two streams must be joined on time, clock discipline is a first-class engineering requirement, not an operational detail. Budget for it explicitly, monitor drift as a metric, and alert on it.

Fan-out without forty pipelines#

Forty consumers, each different, is a recipe for forty bespoke integrations that nobody can maintain. The pattern that survives is the one used across media and, increasingly, everywhere else:

A canonical internal representation. One event schema, one asset model, one identifier space. Everything upstream normalises into it; nothing downstream reads a source format directly. Non-negotiable, and the discipline breaks the first time someone is in a hurry.

Adapters at the boundary. Each consumer gets a thin transformation from canonical to their required shape. Thin is the operative word — when an adapter starts containing business logic, that logic has escaped the core and will diverge across the other thirty-nine.

Idempotent, replayable delivery. A consumer that misses an hour should be able to catch up from the log without a human intervening. In a five-week event with no maintenance window, any recovery procedure that requires a person is a procedure that fails at 3am.

Per-consumer observability. Aggregate pipeline health tells you nothing when consumer 17 is silently failing. Every output needs its own freshness, error rate and volume metrics, with alerting owned by someone.

This is exactly the architecture we build for clients who have never touched video. A hospital group feeding twelve downstream systems from one clinical event spine has the same problem with different nouns. A school trust distributing timetable and attendance changes to a learning platform, a catering system, a transport provider and a parent app has it at smaller scale — and hits the same failure, where each integration was built separately and nobody can now change the core without breaking four of them.

What I would take away#

Three things generalise cleanly from broadcast to ordinary enterprise work:

1. Metadata density determines what is possible. You cannot personalise, search, or automate over content you have not described. The annotation and tagging layer is the product, not overhead.
2. Personalise the assembly, not the artefact. Pre-compute the expensive pieces once; vary the cheap composition per user. Any design where per-user cost scales with expensive computation will not survive its own success.
3. One canonical model, thin adapters, replayable delivery. Forty consumers is only manageable if thirty-nine of them are configuration rather than code.

The tournament delivered every match, in UHD, to forty different architectures, for five weeks, with no downtime. Not because anyone invented something novel — because the boundaries were drawn properly and the clocks agreed.

---

Most personalisation projects fail on metadata and fan-out, then blame the model. We build the canonical layer that makes the interesting part possible. Show us your consumers.