117 Tbps: What the World Cup Final Taught Us About Planning for Peak

At 21:57 UTC on 19 July 2026, Amazon CloudFront moved 117 Tbps. That is the largest live-streaming moment the platform has ever carried, and it is roughly 5.1 times the 23 Tbps peak set by the 2022 final.

The number is fun. The engineering underneath it is more useful, because almost none of it is about having more capacity. It is about shaping demand so the capacity you have is not wasted.

Live is a different problem from big#

Most engineers who have not run live video assume it is a scaling problem with a familiar answer: put a CDN in front and the cache absorbs it. That intuition is wrong in a specific way, and the way it is wrong is the whole discipline.

Video-on-demand is embarrassingly cacheable. A million people watch the same file over a week, the edge fills once, and your origin sees almost nothing. Live inverts every property of that. Each segment is a new object that did not exist two seconds ago, every viewer wants it in the same two-second window, and cache warmth is not something you build up — it is something you achieve in milliseconds or not at all.

So the failure mode for live is not bandwidth exhaustion at the edge. It is a thundering herd on origin. Hundreds of edge locations simultaneously discover they do not have segment number 9,412, and all of them ask the origin for it at once. Your origin, which was comfortable a second ago, now takes hundreds of identical requests per segment, and the segments keep coming every two seconds forever.

The three moves that actually matter#

Reading through the published architecture for this tournament, three techniques carry most of the weight.

Origin shield collapses the fan-in. A regional caching tier sits between the edge fleet and the origin. Hundreds of concurrent cache-fill requests for the same segment become a single fetch per segment per region. This is the single highest-leverage thing in live delivery, and it is a configuration flag on most CDNs that a surprising number of teams never turn on. The economics are absurd in your favour: one origin request instead of several hundred, for every segment, for every one of 104 matches.

Embedded PoPs move the edge inside the ISP. Beyond the 750-plus metro locations, over 1,140 points of presence sit inside ISP networks. In the US and Thailand these served over 80% of match traffic. That traffic never crosses a peering point. It never touches transit. It goes from a cache inside the subscriber’s own provider to the subscriber, which is both faster and structurally immune to the congestion that shows up at interconnects during exactly these events. DE-CIX registered a record 28.4 Tbit/s during Portugal–Spain on 7 June, which tells you what the interconnect layer looked like when it was not bypassed.

Auth moved to the edge. Token validation ran as an edge function at sub-millisecond latency. This is a small thing that becomes a large thing at scale: if entitlement checks call back to a central service, that service is now on the critical path of every segment request from every viewer on the planet, and it becomes the actual bottleneck long before bandwidth does.

The demand curve is not a curve#

The distribution details are the part I would put in front of a capacity planner.

Opening day peaked at 35 Tbps. Group stage topped out at 45 Tbps for Germany–Curaçao. Nine matches individually exceeded 70 Tbps. Then the final hit 117.

That is not a growth curve. That is a series of step functions with a spike at the end, and it means the honest planning question is not “what is our average” but “what is our worst simultaneous minute, and what triggers it.”

The triggers are cultural, not technical. Argentina’s matches drew 2.4 times their tournament average. England matches pulled 3.7 times more traffic from the UK. One Colombian broadcaster escalated from 2.6 Tbps to 9.1 Tbps across the tournament — a 3.5x organic growth in a five-week window, driven entirely by a team winning.

Device mix moves the number too, and moves it more than most people expect. Connected TV dominated at 55–74.5% of traffic in most markets — 65% in the US, 61% in the UK. Connected TVs pull the top rung of the bitrate ladder. The UK peak involved 1.43 million concurrent viewers taking full UHD segments at 25 Mbps each. Turkey was the outlier at 40% mobile and only 10% connected TV, and consequently a very different bytes-per-viewer profile.

That is the real lesson: your peak bandwidth is concurrent viewers multiplied by device mix, and device mix is a regional variable you do not control. A million mobile viewers and a million TV viewers are not the same load. Anyone planning from a headcount number without the mix is planning from the wrong number.

Scaling this down to the systems most of us run#

Almost nobody reading this will serve 117 Tbps. That does not make the pattern irrelevant, because the shape recurs at every size.

We see the identical curve on a School ERP the morning board results publish. Fifty weeks of gentle, predictable load, then one hour where every parent in the district refreshes the same page. It is live-event traffic in every meaningful respect: synchronised, unshiftable, and pointed at content that did not exist a minute ago.

A Hospital Management System has a quieter version — shift-change dashboards, month-end billing runs, the 08:00 wave when outpatient registration opens. Same principle: identify the synchronised moment, then ask whether your origin can survive the fan-in when caches are cold.

The playbook transfers almost line for line:

• Turn on the shielding tier. If your CDN offers a mid-tier cache, use it. Collapsing cache-fill is free performance.
• Make hot objects genuinely cacheable. One personalised query parameter fragments a shared object into a million private ones and silently converts your CDN into an expensive proxy.
• Push auth and routing to the edge. Anything on the critical path of every request should not be a round trip to your core.
• Rehearse the peak, do not model it. Nine matches over 70 Tbps before the final was not luck; it was a five-week ramp that validated the system against progressively harder load. Your equivalent is a load test scheduled before results day, not a dashboard you watch during it.
• Plan for failover in milliseconds, not minutes. Native origin failover rerouting in milliseconds is the difference between a blip and a trending outage.

Forty different broadcaster architectures, 54-plus countries, 104 matches, every one delivered in full UHD for the first time in the tournament’s history. It held. Not because someone provisioned 117 Tbps of headroom, but because the design made sure that almost none of that traffic had to travel far or ask the origin twice.

---

If your traffic has one hour a year that decides whether people trust your platform, that hour deserves an architecture, not a hope. We build and rehearse them. Tell us when your peak is.