The internet has fewer cables than you think

In September 2025, users across Asia and the Middle East saw cloud services slow down. Microsoft confirmed the cause: submarine cable cuts in the Red Sea. Multiple systems were damaged at once — SEA-ME-WE-4, IMEWE, FALCON GCX and Europe India Gateway among them — all carrying traffic between Europe, the Middle East and Asia.

Not a data centre outage. Not a BGP mistake. Physical cable, on a seabed, cut.

The redundancy is thinner than the mental model

Most application engineers hold a mental model of the internet as a dense mesh: if one path fails, traffic reroutes and you might notice a few milliseconds. For traffic within a well-connected region, that model is roughly right.

For traffic between regions, it is much less right than it appears. Intercontinental capacity runs through a relatively small number of physical systems along a small number of viable routes, and those routes bunch through the same chokepoints — the Red Sea being the obvious one. When several systems in the same corridor are damaged in the same incident, "reroute" means pushing the load onto paths that were not provisioned for it. The result is not an outage. It is congestion, latency and timeouts, which is harder to diagnose and much harder to explain to users.

The regional picture is worse than the global one. Vietnam has seen recurring simultaneous failures across its main international systems, with roughly 30% of aggregate international bandwidth impaired during major multi-cable incidents. Terrestrial fibre provides some redundancy, but those routes have their own failure modes — construction, monsoon flooding, and damage to aerial cable.

Why this is an application concern

It is easy to file this under someone else's infrastructure. Three reasons not to.

Your dependencies are further away than your users. A user in Kathmandu hitting a service in Singapore is one hop in your diagram and several thousand kilometres of physical cable in reality. Every third-party API call, font, analytics beacon and CDN miss is a separate opportunity for that distance to matter.

Degradation is not failure. These events rarely produce clean errors. They produce elevated latency and intermittent timeouts, which is the failure mode most codebases handle worst. A hard connection refusal triggers your error path. A request that takes 40 seconds and then succeeds usually triggers nothing at all except a user closing the tab.

Retries make it worse. A congested link plus aggressive client retries is a well-documented way to convert a slowdown into an outage. If your retry policy is a fixed three attempts with no backoff and no jitter, you are contributing load precisely when the path is saturated.

What is actually worth building

None of this argues for building your own network. It argues for a handful of specific properties that are cheap when designed in.

Set explicit timeouts on every outbound call. The default in most HTTP clients is far too long or absent entirely, which means your request queue depth becomes the real timeout.

Use exponential backoff with jitter, and cap total attempts. This is well-trodden and still frequently missing.

Degrade rather than fail. Decide in advance which parts of a page or flow are essential and which can be skipped when their dependency is slow. A checkout that completes without loading the recommendations panel is a working checkout.

Cache aggressively at the edge nearest your users, and be honest about what can be stale. During a multi-cable event, a slightly old cached response is dramatically better than a fresh one that never arrives.

Know where your dependencies actually resolve. Most teams cannot say which region serves their third-party APIs. That is a ten-minute investigation that occasionally reveals something alarming.

The direction of travel

Governments have begun treating this as strategic rather than technical. ASEAN is moving toward clearer regional standards on cable repair and resilience, and the UN established its first advisory body on subsea cable networks in late 2024. Repair capacity — specialised ships, and permission to operate in contested waters — is the binding constraint, and it is not one that software solves.

For those of us building on top, the practical takeaway is smaller and more useful. The network is not a utility. It is infrastructure with a small number of physical components, some of them in politically difficult water, and occasionally a ship's anchor is part of your dependency graph.