The Internet & Digital Networks
Why the Internet Was Designed to Survive a Nuclear War
Every message you send online is torn apart, scattered across dozens of different routes, and reassembled at the other end — and this apparent chaos is the most elegant engineering decision in history.
The Idea
Before the internet existed, communication networks worked like telephone calls: a dedicated line was held open between two points for the entire duration of a conversation. It was reliable, but catastrophically fragile. Knock out the right node and you sever the connection entirely. In the early 1960s, with the Cold War at its height, the US military had a serious problem: how do you build a communications network that keeps working even after a nuclear strike? The answer, developed independently by Paul Baran at RAND and Donald Davies at the UK's National Physical Laboratory, was packet switching. Instead of reserving a continuous line, you break every message into small, standardised chunks — packets — each labelled with its destination address. These packets are then released into a network of interconnected nodes, and each node makes its own local decision about the best route forward. The packets may take completely different paths through the network, arriving out of order, and are only reassembled into the original message at the destination. What makes this so powerful is its resilience through redundancy. If several nodes are destroyed, the remaining ones reroute around the damage automatically — no central authority required, no single point of failure. The network doesn't break; it adapts. This same principle is what allows your video call to keep working when one undersea cable gets severed, and why the internet has no off switch.
In the World
In August 2011, Hurricane Irene battered the eastern United States and knocked out infrastructure across several states. Data centres lost power, cell towers went dark, and local phone exchanges failed entirely. And yet, for most people with an internet connection, email and web traffic continued to flow — rerouted through unaffected nodes with no human intervention. This wasn't luck. It was packet switching doing exactly what Paul Baran had envisioned in 1964. Baran's original RAND memoranda — a twelve-volume document titled 'On Distributed Communications' — described a network with no hub, no centre, no critical artery. He mapped out how messages would be broken into what he called 'message blocks' and would find their own way through a mesh of nodes, each one both a receiver and a router. His superiors at the Air Force were sceptical. AT&T, which ran the US telephone network, was openly hostile — the idea made their entire infrastructure model look vulnerable and obsolete. Baran's proposal sat on a shelf for years. When the ARPANET (the internet's direct ancestor) was eventually built in 1969, it used packet switching almost exactly as Baran had specified, though the engineers later admitted they had initially rediscovered the principle independently before tracing it back to his work. A Cold War defence obsession had quietly become the operating logic of modern civilisation.
Why It Matters
Understanding packet switching changes how you think about resilience in general — not just in networks, but in any complex system. The instinct when building something important is to make it stronger at the centre: a more powerful server, a more fortified hub, a single authoritative source. Packet switching suggests the opposite approach is often smarter: distribute the intelligence to the edges, build in redundancy, and let the system route around failure rather than trying to prevent failure altogether. It also reframes what the internet actually is. It's easy to think of it as a kind of vast plumbing system, with data flowing like water through fixed pipes. But it's closer to a city of billions of independent couriers, each packet making its own journey, none of them knowing the full picture. Your Netflix stream, this lesson, a surgeon's remote-diagnostic data — all of it fragmented, scattered, and silently reassembled thousands of times a day. Once you see that, you'll notice the same tension everywhere: centralised control versus distributed resilience. It turns out the internet didn't just solve a military problem. It modelled a principle.
A Question to Ponder
Where in your own life or work are you building around a single critical node — and what would it look like to route around that vulnerability instead?
Get a new one of these every morning.
Start learning with Thinkable