What happens to the internet when everyone presses play?

When a World Cup final kicks off, Patch Tuesday hits millions of endpoints at once or a major game release drops, millions of people and devices suddenly want a lot of the same bytes at roughly the same time.

Usually, the internet just deals with it. But there’s a huge amount of engineering that goes into managing a surge in demand: caches, internet exchanges, routers, fiber, mobile towers, submarine cables and content platforms all have to work together to keep traffic moving.

Here’s how we make sure the network is up to the task so that nothing breaks when everyone arrives at once.

Don’t plan only for an average day

Network budgets and capacity plans are often based on averages: typical busy-hour traffic, regular use and the cost of bandwidth.

But averages can make you feel safer than you really are. Your network can work perfectly most of the time but struggle when everybody wants the same thing at once — exactly when users are most likely to notice.

This is why network planning must also account for how much traffic might arrive at the same time, and what happens if something breaks at exactly that moment. That means having headroom. Some capacity will remain unused much of the time, but its value becomes clear at peak demand.

Caching is how the internet keeps up

The internet doesn’t fetch every video or game update from a server far away. It moves the content closer, so the same traffic doesn’t travel the world repeatedly. Content delivery networks distribute popular content across infrastructure in different cities and regions, including caches deep inside service-provider networks.

So, when 100,000 people watch the same 8 megabits per second (Mbps) stream, we don’t necessarily need to move 800 gigabits per second (Gbps) across international transit links. If the content is cached locally or regionally, the traffic travels a shorter distance and uses fewer external networks.

Caching isn’t just about shaving a few milliseconds off a web request. At scale, it’s a way of avoiding traffic that never had to move across the network in the first place.

Content locality is capacity engineering

For Africa, this is especially important. International connectivity has changed enormously over the past two decades, and we have much more capacity and diversity than we used to.

However, geography hasn’t changed: Johannesburg to London is still Johannesburg to London. Physics remains stubbornly resistant to software updates. So, the more content we can bring closer to users in Africa, the less work the international layer has to do.

None of this is new. Thirty years ago, local File Transfer Protocol (FTP) mirrors avoided pulling the same software versions across expensive international links again and again. If you wanted the latest FreeBSD release, the sensible place to get it wasn't necessarily a machine on another continent. It was a mirror closer to home. Today we're moving 4K videos, major game releases and massive software updates.

The scale and tooling have changed, but the engineering principle is the same: If everyone wants the same bytes, put the bytes closer to everyone.

The traffic you’re sending out also matters

Say you’re streaming a gaming session. Your traffic needs to reach an ingest point before the platform can process it and distribute it to your viewers. The location of your nearest ingest point is important: If it’s on another continent, you’ve already added an international dependency before your stream has even begun its journey back to the audience.

Regional ingest infrastructure gives that traffic an entry point that’s closer to the streaming platform.

Bandwidth also matters, but once you have enough of it, adding more won’t shorten the distance your traffic has to travel. What matters is where the traffic enters the network, how far it travels and how predictable that path is.

Whereas bandwidth makes the road wider, locality makes the journey shorter.

Big bandwidth doesn’t guarantee a good experience

Too often, network performance is reduced to bandwidth, which isn’t the whole story. Plenty of bandwidth won’t help if a poorly chosen route sends traffic unnecessarily through distant networks and locations. You also have to consider:

• Peering: Directly exchanging traffic with the networks carrying the content your users want can remove entire dependencies from the path.
• Latency and jitter: These are particularly important for gaming, voice and other real-time applications.
• Packet loss: Even a small amount in the wrong place can cause a surprisingly large amount of pain.
• Congestion: A path that works perfectly earlier in the day can behave very differently one minute before the World Cup final kicks off.

The access network is important too. For many users in Africa, pressing play means starting on mobile, where thousands of people attached to the same part of the network can create congestion even when everything upstream is behaving perfectly.

Frustrated users don’t care which part of the architecture failed, but you must.

Keep traffic local when it makes sense

Networks don’t have to send everything through upstream transit providers. They can exchange traffic at an Internet exchange or, where volumes justify it, interconnect privately through peering.

South Africa is a good example. The country’s internet exchange ecosystem, including INX‘s JINX, CINX and DINX exchanges, NAPAfrica and a range of private peering relationships, gives networks multiple places and ways to exchange traffic directly.

If two networks in Johannesburg are exchanging huge volumes of traffic, sending those packets on an international sightseeing tour before bringing them back isn’t clever engineering. Keep the path short when you can, and remove unnecessary dependencies. Use expensive, long-distance infrastructure for traffic that actually needs to travel long distances.

What happens when a route disappears?

Something always breaks — whether it’s a fiber cut, a failing router or an outage at an upstream provider.

The Border Gateway Protocol (BGP), which determines how traffic is routed between networks across the internet, will quite happily find another route without checking whether that route is ready for a World Cup final. But BGP’s job is only to find a reachable path, not guarantee that the path has enough spare capacity for everything you're about to send through it.

To keep the World Cup final streaming, you need an alternative route with enough capacity, and this is where resilience gets expensive.

Africa’s international connectivity adds another physical reality: submarine cables. When one fails, networks can reroute quickly, but repairing the cable itself can take considerably longer.

Whether users notice depends on what happens after the reroute. Do other paths have enough capacity? Does routing behave the way you expected? How much traffic could have stayed local instead?

Redundancy without capacity isn’t redundancy. The goal is to make sure the internet still works after the failure — preferably without the person watching their favorite football team ever knowing anything happened.

Power supply is another variable in Africa

Most of the engineering for a major online event happens before anyone presses play. Network teams review capacity, model traffic patterns, and check peering and routing with content providers and other network partners.

In parts of Africa, we have another variable to worry about: power. A well-engineered 400 Gbps link is considerably less impressive when the equipment at the other end goes dark.

So, resilience planning should also include batteries, generators, UPS systems and fuel at remote sites, and calculating how long everything will keep running when the grid fails.

What this looks like from our perspective

At NTT DATA, we deal with these questions inside the network every day. For AS20011 and AS3741 — the autonomous systems behind our national broadband and international transit platforms — we consider how much capacity exists and where it exists; where content enters and leaves the network.

Then we make sure we know what happens when one of those paths disappears, and whether the remaining network can carry the load without users noticing.

Our interconnections within South Africa’s internet exchange ecosystem, including JINX, CINX, DINX and NAPAfrica, are part of that design.

In 2026, we crossed 400 Gbps of active peering capacity at JINX — in other words, provisioned interconnection capacity that’s active and ready when demand arrives (we’re not claiming that 400 Gbps of traffic passed through JINX at a particular moment!).

And that’s really the point. Traffic keeps growing, more content is moving closer to users in Africa, and applications are becoming increasingly sensitive to latency. The network has to be ready.

The internet is bigger than the backbone

A well-engineered internet backbone solves only part of the problem. The wide area network connecting your organization’s sites, the cloud platforms delivering applications, the security services protecting them, the access networks reaching users and the operational teams that keep it running all contribute to the same experience.

That’s why modern networks have to be treated as systems. Capacity, routing, locality, resilience, observability, automation, security and the people operating it are all equally important to the user experience, and every one of those pieces has to work.

The user pressed play. Did it play?

Everything else is engineering.

• ALSO READ: Keeping your network running isn’t enough anymore

What to do next

Read more about NTT DATA’s infrastructure services to see how we provide reliable, secure solutions that help you adapt quickly and work more efficiently.