Global performance issues rarely start in your data center, your cloud provider, or your application. They start thousands of miles away, under the ocean, on routes you probably never chose and rarely think about.
One of the biggest misconceptions I still see is that the cloud removes geography. It doesn’t. Data still traverses real, physical paths across land, borders, and the ocean floor, through a mix of carriers, subsea systems, and landing points. There are roughly 400 active subsea cable systems globally, and they underpin everything from cloud applications to video calls and payments.
Most of the time, this infrastructure works quietly in the background. But when a path degrades or fails entirely, traffic doesn’t stop. It reroutes onto whatever alternative is available, often longer, more congested, or not designed for that volume.
The Real Problem Isn’t the Reroute
Most global routing wasn’t designed for how networks actually work today. It evolved over time, inherited and rarely re-architected. Meanwhile, everything else changed: cloud adoption, user distribution, acquisitions, application behavior, and business criticality.
So when a route degrades, traffic shifts. But that shift isn’t always obvious or easy to interpret in standard monitoring tools. It could even be that your carrier’s Service Level Agreement (SLA) still shows green. Packet loss looks fine. Uptime is intact. But those metrics don’t reflect real user experience across multi-provider international paths with multiple handoffs between carriers and subsea systems.
And that’s where the disconnect shows up, and in practice, it looks like:
-
- delayed transactions
- inconsistent voice quality
- stalled application sessions
- users blaming “the cloud”
The issue isn’t where you’re looking. It’s where you can’t see or control.
What This Looks Like in Practice
I see this play out more often than most teams realize.
One customer, a global shipping company, had two Europe–Asia routes that crossed the Red Sea that were unstable and caused continual, expensive problems. This wasn’t new. They’d been trying to fix it for over a year. Multiple providers were involved, but none could meet the full performance and security requirements across the path.
That is because there isn’t an off-the-shelf answer. Enterprises operating at this level aren’t choosing from an open menu. They’re working within what physically exists, and sometimes what exists isn’t enough without someone who knows how to architect around it.
Traditional providers optimize within their own network, but here’s the thing: This problem didn’t sit inside a single network. It sat across carriers, across subsea systems, and across regions no single provider could fully control.
So instead of trying to force a standard solution to fit, we engineered a path around the constraint, combining multiple carriers and taking end-to-end ownership of the result. We didn’t try to fix the Red Sea problem (we’re good, but even we can’t move the sea floor or stop dragging the anchor). So what did we do? We went around it entirely.
What You Can Take Away
While the geography was specific, the problem wasn’t. Most enterprises with international traffic have a network design that was scoped once, handed to a carrier, and never seriously revisited.
I always like to start with these three questions to help teams figure out if their global network design is as resilient as it needs to be:
- Do you know what subsea systems your international traffic crosses? Not in theory, but actually, for your specific routes. If the answer is “I’d have to ask our carrier,” that’s a gap. If the answer is “I’m not sure we have international traffic,” check again, as the cloud traffic to US-East from anywhere in Europe or Asia crosses subsea infrastructure.
- When did you last review your global routing design? If it was set up when you onboarded a carrier two or three years ago and nobody’s touched it since, it was designed for a network that probably doesn’t look like yours anymore. Acquisitions, cloud migrations, new sites, all of it changes your traffic patterns without necessarily changing your routing.
- Do you have an alternative path named if your primary route degrades? Not “our carrier will handle it.” A specific answer: what path, through what systems, with what latency profile. If that answer doesn’t exist, you have a single point of failure you’ve never stress-tested.
If you can’t answer at least two of those cleanly, your global routing is probably worth a proper look.
Resilient Global Routing Isn’t Accidental. It’s Engineered.
It starts with knowing which subsea systems your traffic depends on and what happens when one of them degrades. It means designing path diversity, not just geographic redundancy. Because geographic redundancy on paper doesn’t guarantee diversity in reality. Two regions can still rely on the same cable system, landing point, or corridor, and fail in the same way.
Whether you’re running trading platforms, telehealth services, e-commerce platforms, logistics networks, factories, or distributed teams, the pattern is consistent: Performance doesn’t fail all at once. You don’t see it first. Your users and customers do.
You don’t need to be an expert in subsea cables. But you should work with people who think about this before there’s a problem. Because when performance drops or routes degrade, the question is never “Who owns the cable?” but “Why didn’t we see this coming?”
In a global, cloud-first world, that question almost always traces back to design decisions that were invisible at the time and ignored for too long.
The cable doesn’t care about your SLA. It doesn’t know your application is business critical. It just carries the traffic, until it doesn’t. The question isn’t whether your routing will face a disruption. It’s whether you’ll see it coming.
Guest Author
Bal Athwal — Vice President, Strategic Global Enterprise Solutions
Bal Athwal works with global enterprises on complex connectivity challenges where standard solutions fall short. His focus is on designing network architectures across large, distributed environments, balancing performance, resilience, and real-world constraints.
His work includes building multi-region connectivity solutions across complex, multi-carrier environments, navigating both the technical and commercial realities of global network infrastructure, and engineering solutions that go beyond standard carrier offerings.
He holds an MBA in Technology Management from Stevens Institute of Technology.