How the Internet Works
The internet is a network of networks. Your device does not connect directly to a server — it goes through routers, ISPs, DNS resolvers, CDNs, and finally the origin. Understanding this chain is the foundation for every system-design decision.
None — start here.
How it works
The internet is a network of networks. Your device does not connect directly to a server hosting example.com — it goes through a chain of intermediaries (router, ISP, DNS resolver, more routers, possibly a CDN, then the origin server). Understanding this chain is the foundation for every system-design decision: where to cache, what to replicate, why latency varies, why connections fail, and why TLS matters.
At the core, the internet moves packets. A packet is a small chunk of data with a source IP, destination IP, and a payload. Routers inspect the destination IP and forward the packet closer to its destination, hop by hop. This is packet switching — many devices share the same physical wires, and each packet finds its own path.
Each hop in the chain can fail, add latency, or be a caching opportunity. System design is largely about deciding what to put where: what to cache at the CDN edge, what to cache at the origin, what to replicate, and what to keep on a single primary.
Above packet switching sits TCP/IP. IP handles addressing and routing. TCP sits on top of IP and provides reliable, ordered, connection-oriented delivery. A TCP connection requires a three-way handshake (SYN, SYN-ACK, ACK) before any application data flows. This is why HTTPS is slower than it looks — every new connection pays the handshake tax. HTTP/2 and HTTP/3 reduce this by multiplexing multiple requests over a single connection (HTTP/2) or using UDP with QUIC (HTTP/3).
Why does HTTPS feel slower than plain HTTP for the first request to a new origin?
Pick one answer.
Why does HTTPS feel slower than plain HTTP for the first request to a new origin?
Pick one answer.
Packet switching in practice. When you stream a 4K video from Netflix, the bits do not travel as one continuous stream over a dedicated wire. The video is broken into ~1,500-byte IP packets, and each packet independently finds its way from Netflix's CDN to your home router. Packet 47 might travel Seattle→Tokyo→Mumbai→your ISP→your home; packet 48 might travel Seattle→LA→Singapore→Mumbai→your ISP→your home. If a submarine cable is cut near Mumbai, only the packets already in flight along that path are affected — subsequent packets immediately take the alternate route.
This is what makes the internet resilient: there is no single wire that, if cut, breaks the whole thing. The cost of this resilience is reordering — packets can arrive out of order, duplicated, or dropped entirely. TCP (the layer above IP) reassembles them in order and retransmits the missing ones. The application never sees the chaos underneath.
What happens when a router fails? Backbone routers run BGP (Border Gateway Protocol) — fundamentally a gossip protocol. Each router announces to its neighbors which IP prefixes it can reach, and how far away they are. When a link or router dies, the affected router withdraws its announcements and re-announces the prefixes through a different neighbor. Every other router on the internet eventually hears about the change and updates its forwarding table. This is BGP convergence.
Convergence is slow — typically 30 seconds to several minutes. During that window, packets destined for the failed path are black-holed (silently dropped). This is why a single misconfigured router can take a major website off the air for thousands of users for several minutes, even though the website itself is perfectly healthy.
Three production incidents illustrate this failure mode: the 2019 Cloudflare BGP leak that black-holed parts of the global routing table; the 2008 Pakistan Telecom incident where a bad BGP announcement hijacked YouTube globally for 2 hours; and the October 2021 Facebook BGP withdrawal that took Facebook, Instagram, and WhatsApp offline for 6 hours. In every case, the data plane (origin servers) was fine — the control plane (BGP) disagreed about where traffic should go.
Cloudflare operates PoPs in ~330 cities worldwide. When a user in Mumbai types example.com, their DNS often resolves to a Cloudflare anycast IP that routes to the nearest edge PoP — typically within 5-20ms of the user. Cloudflare terminates the TLS handshake at the edge, serves cached static assets directly, and only contacts the origin (often in Virginia or Frankfurt) for dynamic content. This collapses the long browser→ISP→BGP→origin chain into a short browser→edge→(sometimes origin) chain, cutting latency from ~300ms to ~30ms. The same architecture underpins Fastly, Akamai, and AWS CloudFront — the principle is identical: push content as close to the user as physically possible.
A core internet router in Chicago fails. Users in New York trying to reach a server in Dallas suddenly see their requests time out for ~90 seconds, then start working again. The server is healthy. What happened?
Pick one answer.
Round-trip time from Mumbai to Virginia is ~280ms. A single page load triggers ~15 sequential HTTPS requests (HTML, CSS, JS chunks, API calls). Without a CDN, every request pays the full RTT plus TCP + TLS handshake.
You run a streaming service in the US with one origin in Virginia. A user in Mumbai reports that pages take 4 seconds to load and frequently stall. Your monitoring shows the Virginia servers respond in 80ms. What is the highest-leverage architectural change?
Engineering mental model
Mental model. Think of How the Internet Works as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does How the Internet Works mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing How the Internet Works, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
// Pseudocode
request = receive()
result = how_the_internet_works(request)
return result
// Production questions:
// 1. What happens on timeout?
// 2. Can this operation be retried safely?
// 3. What is the bottleneck?Back-of-the-envelope reasoning
Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.
Interactive thought experiment: How the Internet Works
Change the variables below and predict what breaks first in How the Internet Works. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on How the Internet Works, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using How the Internet Works. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using How the Internet Works?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses How the Internet Works, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose How the Internet Works, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
A useful engineering lens for How the Internet Works: define the problem it solves, the simpler design that fails first, the constraint that forces you to introduce this concept, and the new failure modes the concept creates.
Numerical sanity check
Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
Imagine the simplest version of a system using How the Internet Works. What breaks first as traffic grows by 10×, and what would you change before reaching 100×?
Pick one answer.
What you gain, what you pay
- +Decentralized — no single owner or point of control.
- +Packet switching efficiently shares expensive long-haul links.
- +Layered protocols allow each layer to evolve independently.
- −Each hop adds latency and a potential failure point.
- −Best-effort delivery — packets can be dropped, reordered, or duplicated.
- −Trust model is fragile — security was bolted on later (TLS, DNSSEC).
How this breaks in production
- A single router failure can blackhole traffic until BGP converges (minutes).
- DNS cache poisoning can redirect users to attacker-controlled servers.
- TLS interception by middleboxes can break certificate pinning.
Don't fall into these traps
- •Treating 'the network' as a black box. In reality, every hop can fail, buffer, or reorder.
- •Assuming bandwidth equals speed. Latency (round-trip time) often dominates user-perceived performance.
- •Forgetting that DNS is a single point of failure for your domain — if DNS is down, you are down.
Real systems using this
How real systems implement this
- Cloudflare — Operates one of the largest edge networks, intercepting requests at 300+ cities worldwide before they reach origin.
- AWS VPC — Isolates your servers in a virtual network with custom routing tables and security groups.
Practice saying it out loud
- Q1Walk me through what happens when you type a URL into a browser and press Enter.
- Q2Why does a request sometimes take 50ms and sometimes 500ms to the same origin?
- Q3If you were designing a global API, where would you place your servers and why?
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
DNS — Domain Name System