The Narrow Waist of the Internet — API Design

Summary#

The Internet has a shape, and the shape is an hourglass. At the top of the hourglass sits everything an application speaks — HTTP, SMTP, DNS, gRPC, WebSocket, QUIC, BitTorrent, SSH, IMAP, SMTP, NTP, and the thousand bespoke protocols layered above them. At the bottom of the hourglass sits everything the wire is — Ethernet, Wi-Fi, fibre, DOCSIS cable, 4G LTE, 5G NR, satellite radio, Bluetooth, undersea cables, copper twisted pair. And in the middle, holding the two halves together by being the only protocol every host on the public Internet must speak, sits the Internet Protocol — IP.

This is the famous “narrow waist”: everything-over-IP at the top, IP-over-everything at the bottom. The waist is narrow on purpose. Because IP is the universal layer, any new application protocol can run anywhere IP runs, and any new physical medium can carry any IP-speaking application. The hourglass is the architectural reason a webcam streams over the same Internet that delivers your bank statements, that the same gRPC client library works over fibre and 4G, that you can build an API today and have it reach every smartphone on the planet without thinking about radio modulation.

For an API designer, the narrow waist is the substrate you stand on. You do not see Ethernet frames or 5G symbol scheduling. You see packets — bounded, addressed, best-effort, possibly reordered, possibly lost. Everything above the waist (TCP, TLS, HTTP, your API) is a story about how to turn that lossy packet abstraction into a useful conversation.

Why it matters#

Three reasons the hourglass shape directly affects how API designers think.

The substrate hides physical-medium variability but exposes packet-level reality. IP gives you a packet abstraction that is the same on fibre and 4G — but IP does not give you reliability, ordering, or congestion control. Those are TCP’s job (or QUIC’s, or your job if you pick UDP). An API designer who forgets that packets can be lost, reordered, delayed, or duplicated will design a contract that breaks the first time the user is on a flaky LTE connection.
The hourglass makes deployment composable. A new transport (QUIC over UDP, 2016) ships without changing the application layer. A new application protocol (gRPC, 2016) ships without changing the transport. A new physical medium (Starlink, 2021) ships without changing anything above IP. This composability is why API designers can ignore the lower half of the hourglass — because the layering is the contract.
The waist is also the chokepoint. IPv4 address exhaustion was a multi-decade migration. NAT (network address translation), which papered over the exhaustion, broke peer-to-peer assumptions and forced every modern API into a “client connects out” pattern. The waist’s design decisions cast long shadows.

The practical upshot is that an API designer who knows the hourglass shape can answer “why is my API slow on mobile?” with the right mental model: the waist is the same, but the lower half (radio link, base station, backhaul) introduces latency, jitter, and packet loss that the upper half (TCP, TLS, HTTP) translates into stalls, retransmits, and head-of-line blocking.

How it works#

The hourglass has three layers, but the deep idea is that the middle layer is deliberately impoverished so that the upper and lower layers can innovate independently.

The lower half: IP-over-everything#

The job of the lower half is to deliver IP packets between two adjacent hops. The mechanisms differ wildly — Ethernet uses CSMA/CD or full-duplex switching, Wi-Fi uses CSMA/CA with backoff, LTE uses scheduled time-frequency resource blocks, fibre uses wavelength-division multiplexing, satellite uses store-and-forward at orbital latencies. Each medium has its own physics, its own MTU, its own loss profile, its own latency floor. The lower half abstracts all of this behind a single interface: “given an IP packet and a next-hop, deliver it.”

The result is that IP runs over every physical medium humans have ever invented for moving bits. The original RFC even joked about IP-over-avian-carrier (RFC 1149, 1990, half-serious) — implemented in 2001 with pigeons in Bergen, Norway, achieving a 55% packet loss rate and 1.5-hour round-trip. The point is not that pigeons are practical; it is that the substrate is so neutral that even pigeons could implement it.

The waist: IP itself#

IP does four things and almost nothing else:

Addressing. Every host gets a 32-bit (IPv4) or 128-bit (IPv6) address. The address is location-dependent (it identifies where the host attaches to the network), not identity-dependent.
Routing. Routers look at the destination address and forward the packet toward it. The path is determined hop-by-hop; the source does not control the route.
Fragmentation. If a packet is bigger than a link’s MTU, IP can fragment it. (In practice, modern Internet practice avoids this via Path MTU Discovery — fragmentation is a footgun.)
Best-effort delivery. No guarantees of arrival, ordering, or non-duplication. If you want those, layer them above.

That is it. IP does not do reliability, ordering, congestion control, flow control, security, identity, or sessions. It moves a packet from address A to address B with best effort. Every other property has to be built on top — which is why TCP exists, why TLS exists, why HTTP exists, why your API exists.

The upper half: everything-over-IP#

Once you have a best-effort packet pipe, you can build anything. TCP builds reliability and ordering on top. UDP keeps the best-effort semantics but adds ports. TLS builds confidentiality and authentication. HTTP builds a request-response abstraction. WebSocket builds a bidirectional stream. gRPC builds RPC semantics with code-generated stubs. Your REST API builds a resource model. Each layer adds properties the layer below did not have, while keeping the lower-layer interface narrow.

              ┌──────────────────────────────────────┐
              │  HTTP · gRPC · WebSocket · SMTP ...  │   application layer
              ├──────────────────────────────────────┤
              │       TCP · UDP · QUIC · SCTP        │   transport layer
              ├──────────────────────────────────────┤
              │                                      │
              │              IP                      │   the waist
              │                                      │
              ├──────────────────────────────────────┤
              │   TCP · UDP · QUIC · SCTP            │   (transports re-shown for completeness)
              ├──────────────────────────────────────┤
              │ Ethernet · Wi-Fi · LTE · 5G · fibre  │   link layer
              ├──────────────────────────────────────┤
              │   copper · radio · light · pigeon    │   physical layer
              └──────────────────────────────────────┘

Variants and trade-offs#

The hourglass has been challenged twice in the past two decades, and the outcome of each challenge is worth knowing.

Mobile IP and identity-vs-location. IP addresses bind identity to location — when a phone moves between Wi-Fi and 4G, its IP changes, and any TCP connection over the old IP breaks. Mobile IP (RFC 5944) tried to fix this with home-address indirection but never deployed widely. Instead, the upper half adapted: QUIC uses connection IDs that survive IP changes, applications added auto-reconnect, mobile SDKs added retry. The waist did not bend; the upper half bent around it.

IPv6 and the slow waist transition. IPv4 ran out of addresses around 2011. IPv6 has been the stated replacement since 1998. As of 2026, IPv6 carries roughly half of public Internet traffic and IPv4 carries the other half. The 28-year transition is itself a lesson — the waist is so load-bearing that changing it takes generations. The reason it took so long is exactly the reason it works: every host on Earth must speak the same waist protocol, and changing every host is a coordination problem with the universe.

The lesson for API designers: anything you put in the waist of your own stack will be similarly hard to change. A widely-adopted API contract acts like IP — every integrator has built on top, and breaking the contract requires coordinating with all of them. Design accordingly.

When this is asked in interviews#

The hourglass rarely shows up by name in an API-design interview, but the mental model it provides shows up constantly. Three specific moments where a candidate who has internalised the hourglass shines:

“Why does this API behave differently on mobile?” The right answer mentions the lower half — radio link variability, NAT, intermittent connectivity, IP-address changes during a session. The wrong answer is “we need to retry harder.”
“How do we evolve this contract over five years?” The right answer treats the contract as if it were the waist — narrow, stable, with growth happening above and below. The wrong answer adds another field every quarter.
“What runs underneath HTTP/3?” UDP, then IP. QUIC is the new transport that ships over the same IP waist. The candidate who can place QUIC in the hourglass — and explain why it ships over UDP rather than directly over IP (because IP is locked down by middleboxes, and UDP is the most-IP-like thing that gets through them) — is signalling deep substrate literacy.

The line worth carrying out of this concept: the narrow waist works because it does almost nothing. Good APIs you design will look the same way.

Network Sockets — The Foundation — the OS-level handle every IP-using process opens to send and receive packets.
The World Wide Web — the upper-half application stack (URI + HTTP + HTML) that runs over the waist.
HTTP — The Foundational Protocol for APIs — the request-response protocol layered above TCP and TLS, which themselves sit above IP.
Latency and Throughput — the performance dimensions every layer above the waist has to manage.
What Is API Design? — the contract framing the hourglass enables.