1. The problem: why should a system designer care about protocols?

When you tap the Instagram icon in Mumbai, the app must fetch your feed from servers that may be thousands of kilometres away. That one tap turns into a DNS lookup, a TCP connection, a TLS handshake, an HTTP request, and then dozens of image downloads — each a conversation made of packets bouncing across undersea cables, routers, carrier networks and load balancers.

System design decisions that look "high level" are really networking decisions in disguise:

• Why have a CDN and edge PoPs? Because round trips across oceans are slow and handshakes need several of them.
• Why does the load balancer terminate TLS? Because TLS is CPU-heavy and certificates need central management.
• Why do DMs use WebSockets, not plain HTTP? Because HTTP is request/response and the server can't otherwise speak first.
• Why did Meta invest heavily in QUIC? Because phones switch networks and lose packets, and TCP handles both badly.

You don't need to be a network engineer to design systems, but you do need a solid mental model of what a request costs. This lesson gives you that model and the vocabulary interviewers expect.

2. Layers: the simplified OSI and TCP/IP models

Networking is organised in layers. Each layer solves one problem and relies on the layer below, so HTTP doesn't need to know whether it's travelling over Wi-Fi or 5G. The academic OSI model has 7 layers; the practical TCP/IP model used on the internet collapses them into 4–5. You'll hear engineers say "L4" and "L7" constantly — those numbers come from OSI.

*TLS sits between transport and application; people variously call it L5/L6 or "part of L7". In QUIC it is built into the transport itself.

Why it matters for design: an L4 load balancer sees only IPs and ports (fast, protocol-agnostic), while an L7 load balancer parses HTTP and can route by URL path, header or cookie (smarter, more expensive). See Load balancing.

2.1 Encapsulation

As data goes down the stack, each layer wraps it with its own header — like nested envelopes. The receiver unwraps them in reverse order.

3. IP addresses, ports and NAT

3.1 IP addresses

An IP address identifies a network interface on the internet, like a building's street address. IPv4 addresses are 32 bits, written as four numbers (157.240.22.174) — about 4.3 billion total, which ran out long ago. IPv6 addresses are 128 bits (2a03:2880:f12f:83:face:b00c:0:25de — yes, Meta embeds "face:b00c" in some of its IPv6 addresses), enough for every device many times over. Large mobile carriers increasingly run IPv6-first networks, and big services serve both.

Some IPv4 ranges are private (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16): usable inside a home, office or data center but not routable on the public internet. The /8 notation (CIDR) says how many leading bits are the network prefix — /8 means the first 8 bits are fixed, leaving 24 bits (16.7M addresses) for hosts.

Routers forward packets based on the destination address using routing tables. Between organisations (called autonomous systems), routes are exchanged with BGP (Border Gateway Protocol): each network announces "I can reach these address prefixes". If a network stops announcing its prefixes, the rest of the internet literally forgets how to reach it — which is exactly what happened in Facebook's October 2021 outage (see DNS).

3.2 Ports

One machine runs many programs, so an IP address alone isn't enough. A port (a 16-bit number, 0–65535) identifies the program/socket — the apartment number in the building. Well-known server ports: 443 HTTPS (and HTTP/3 over UDP 443), 80 HTTP, 53 DNS, 22 SSH, 5432 PostgreSQL, 6379 Redis, 9092 Kafka. Clients use a random ephemeral port (e.g. 51234) for each outgoing connection.

A TCP connection is uniquely identified by its 5-tuple: (protocol, source IP, source port, destination IP, destination port). Load balancers hash this tuple to keep all packets of one connection on the same backend.

3.3 NAT (Network Address Translation)

Because IPv4 addresses are scarce, your home router gives devices private addresses (192.168.1.23) and translates them to its single public address on the way out, remembering the mapping in a table so replies can be sent back to the right device. Mobile carriers do the same at enormous scale — carrier-grade NAT (CGNAT) — so thousands of phones may share one public IPv4 address.

 Phone 10.20.3.7:51234 ──┐                         ┌──> 157.240.x.x:443 (Instagram edge)
 Phone 10.20.9.1:40001 ──┼─> Carrier NAT 49.36.1.5 ─┤   sees both as 49.36.1.5 (ports 61001, 61002)
 Phone 10.20.4.4:33333 ──┘   table:                 └──> ...
                             10.20.3.7:51234 ⇄ 49.36.1.5:61001
                             10.20.9.1:40001 ⇄ 49.36.1.5:61002   (entries expire when idle!)

Design consequences:

• Idle connections die silently. NAT tables drop idle entries (sometimes after only 30 seconds to a few minutes on mobile). Long-lived connections like DM WebSockets or MQTT must send small keep-alive heartbeats, or the NAT forgets them and the server's next message vanishes.
• IP-based rate limiting is crude. Thousands of legitimate users can share one carrier IP; limiting per IP would punish all of them. Rate limit per user/token where possible (see Rate limiting).
• Servers can't initiate connections to phones. The phone has no public address; the server can only talk back over a connection the phone opened — which is why push uses APNs/FCM or a client-opened persistent connection.

4. TCP vs UDP

The transport layer offers two classic choices:

• TCP (Transmission Control Protocol) gives a reliable, ordered byte stream: what you send arrives complete, in order, without duplicates — or the connection reports an error. It achieves this with handshakes, sequence numbers, acknowledgements and retransmissions, and it slows down when the network is congested.
• UDP (User Datagram Protocol) sends individual datagrams with almost nothing added: no connection, no delivery guarantee, no ordering, no congestion control. It's a thin layer over IP that adds ports and a checksum. Applications that need reliability build their own on top (as QUIC does).

Rule of thumb: if losing or reordering data is unacceptable and you don't want to build reliability yourself, use TCP. If timeliness beats completeness (a video call would rather skip a late frame than wait), or you want to implement a smarter transport in user space (QUIC), use UDP.

5. How TCP works

5.1 The three-way handshake

Before any data flows, client and server agree to talk and exchange starting sequence numbers (counters used to number every byte so the receiver can reorder and detect gaps):

 Client (phone)                                         Server (edge LB)
     |  SYN  seq=x            "I want to talk; my bytes start at x"   |
     |----------------------------------------------------------->  |
     |  SYN-ACK  seq=y, ack=x+1   "OK; mine start at y; got your x"   |
     |  <----------------------------------------------------------- |
     |  ACK  ack=y+1   (can already carry the first request bytes)    |
     |----------------------------------------------------------->  |
     |<================= 1 full RTT before the request goes ========>|

The client can send data together with the final ACK, so the handshake costs exactly one round trip before the request leaves. Closing a connection uses a FIN/ACK exchange; an abrupt close uses a RST packet. (TCP Fast Open can send data in the SYN on repeat connections, but middlebox problems limited its adoption — one of the motivations for QUIC.)

5.2 Reliability: sequence numbers, ACKs and retransmission

• Every byte has a sequence number. The receiver sends ACKs ("I've received everything up to byte 14,600").
• If the sender doesn't get an ACK within a retransmission timeout (RTO) — derived from measured RTT — or sees three duplicate ACKs (a strong hint a packet was lost), it resends.
• The receiver reassembles bytes in order and hands the application a clean stream. A gap means later bytes wait in a buffer until the missing packet arrives: this is TCP head-of-line blocking.
• Flow control: the receiver advertises a receive window ("I have buffer space for 64 KB more") so a fast sender can't overwhelm a slow receiver.

5.3 Congestion control: the intuition

The network itself has limited capacity. If every sender blasted at full speed, router queues would overflow and everyone's packets would be dropped (congestion collapse). TCP therefore keeps a congestion window (cwnd) — how many unacknowledged bytes it may have "in flight":

1. Slow start: a new connection starts small — typically 10 segments (≈14 KB) — and doubles cwnd every RTT while ACKs keep coming back: 14 KB → 28 → 56 → 112…
2. Congestion avoidance: after a threshold, grow more gently (roughly +1 segment per RTT).
3. On loss: assume congestion and cut cwnd (classic algorithms halve it — "additive increase, multiplicative decrease", AIMD). Modern Linux defaults to CUBIC; Google's BBR instead estimates bottleneck bandwidth and RTT directly and copes better with random (non-congestion) loss common on wireless links.

The consequence for designers: a new connection is slow even on a fat pipe. Downloading a 100 KB feed response on a fresh connection needs several RTTs of slow start (14 + 28 + 56 = 98 KB after 3 RTTs). On a reused, "warm" connection whose cwnd has already grown, the same response may arrive in one RTT. That's another reason to reuse connections and to place servers close to users.

bytes delivered after k RTTs of slow start ≈ initcwnd × (2^k − 1)
initcwnd = 14 KB:  k=1 → 14 KB, k=2 → 42 KB, k=3 → 98 KB, k=4 → 210 KB
→ a 200 KB image on a brand-new connection needs ~4 RTTs of transfer time.
   Mumbai ⇄ local PoP (20 ms RTT): ~80 ms.  Mumbai ⇄ US (220 ms RTT): ~880 ms.

6. TLS: encryption and its handshake cost

TLS (Transport Layer Security) — the "S" in HTTPS — gives three guarantees: confidentiality (nobody on the path can read the data), integrity (nobody can modify it undetected) and authentication (you're really talking to instagram.com, not an impostor on the café Wi-Fi).

6.1 The building blocks

• Certificates: the server presents a certificate binding its hostname to a public key, signed by a Certificate Authority (CA) the device already trusts. The client verifies the chain (leaf → intermediate → root) and the hostname.
• Key exchange: client and server use (elliptic-curve) Diffie–Hellman to agree on a shared secret over the open network without ever sending it. With ephemeral keys this gives forward secrecy: stealing the server's private key later doesn't decrypt old recorded traffic.
• Symmetric encryption: the actual data is encrypted with fast ciphers (AES-GCM, ChaCha20-Poly1305) using keys derived from that secret. Asymmetric crypto is only used in the handshake because it's expensive.
• SNI (Server Name Indication): the client says which hostname it wants in the first message, so one IP/load balancer can serve many certificates (i.instagram.com, www.instagram.com, CDN hosts).

6.2 TLS 1.2 vs TLS 1.3 handshakes

 TLS 1.2 (after TCP handshake)                    TLS 1.3 (after TCP handshake)
 Client                     Server                Client                     Server
   | ClientHello -------------> |                   | ClientHello + key share -> |
   | <- ServerHello, Cert,       |                   | <- ServerHello + key share,|
   |    ServerKeyExchange, Done  |   RTT 1           |    Cert, Finished          |  RTT 1
   | ClientKeyExchange,          |                   | Finished + HTTP request -> |
   | ChangeCipherSpec, Finished->|                   | <------- HTTP response ---- |  RTT 2
   | <- ChangeCipherSpec,Finished|   RTT 2           |
   | HTTP request -------------->|                   |  Resumed with PSK + 0-RTT:
   | <------------ HTTP response |   RTT 3           |  ClientHello + early data (request) ->
                                                     |  <- response               |  RTT 1 (total)

Where TLS ends is a design decision. Instagram-style systems terminate TLS at the edge — the CDN PoP or the edge load balancer — close to the user, so the expensive handshake round trips are short. Traffic from the edge to the data center travels over long-lived, pre-warmed, re-encrypted connections. Inside the data center, service-to-service calls are increasingly encrypted too (mutual TLS) — see Security.

7. HTTP: the language of the web and of APIs

HTTP (HyperText Transfer Protocol) is a request/response protocol: the client sends a request, the server sends exactly one response. Every Instagram API call — load feed, like, follow, get an upload URL — is an HTTP request (REST/GraphQL-style, see API design), and every image download from the CDN is an HTTP GET.

7.1 Anatomy of a request and response

POST /api/v1/media/3141592653/like/ HTTP/1.1         ← request line: METHOD  PATH  VERSION
Host: i.instagram.com                                ← headers: metadata about the request
User-Agent: Instagram 300.0.0.0 Android (33/13; …)
Authorization: Bearer eyJhbGciOi…                    ← who you are (see Authentication lesson)
Content-Type: application/json
Content-Length: 46
Idempotency-Key: 7f3e2a10-…                          ← makes retries safe
Accept-Encoding: gzip, br
                                                     ← blank line ends the headers
{"container_module":"feed_timeline","radio":"wifi"}  ← body (optional)

HTTP/1.1 200 OK                                      ← status line: VERSION  CODE  REASON
Content-Type: application/json
Content-Encoding: gzip
Cache-Control: private, no-store                     ← personalised: never cache in shared caches
X-Request-Id: 9b1c…                                  ← for tracing (see Observability)

{"status":"ok","like_count":57,"has_liked":true}

Parts to know: the method (what to do), the path (which resource), headers (metadata — auth, content type, caching, compression), and the optional body. Responses carry a status code, headers and body. In HTTP/2 and HTTP/3 the same concepts exist, but the request line becomes "pseudo-headers" (:method, :path, :authority) in a compressed binary encoding.

7.2 Methods

Idempotency matters because networks fail: if a response is lost, the client doesn't know whether the server acted. Retrying an idempotent request is always safe; retrying a non-idempotent one needs an idempotency key the server deduplicates. See Resilience patterns.

7.3 Status codes

Memory aid: 2xx = success, 3xx = go elsewhere / use your cache, 4xx = you (the client) did something wrong, 5xx = we (the server) did.

8. HTTP/1.1: keep-alive and head-of-line blocking

HTTP/1.0 opened a new TCP connection for every request — a handshake (and later a TLS handshake) per image. HTTP/1.1 (1997) made connections persistent by default (keep-alive): after a response, the connection stays open for the next request, saving the handshake round trips and keeping TCP's congestion window warm.

But HTTP/1.1 is still one request at a time per connection: the response to request #1 must be fully received before #2's response can start. (HTTP pipelining tried to let clients send several requests without waiting, but responses still had to come back in order, and buggy proxies made it unusable — browsers disabled it.) If response #1 is slow — a big image or a slow database query — everything queued behind it waits. This is application-level head-of-line (HOL) blocking.

Workarounds became folklore:

• Multiple connections: browsers open up to ~6 connections per hostname in parallel — six times the handshakes and six congestion windows competing.
• Domain sharding: spread assets over img1.example.com, img2… to get 6 connections each. More DNS lookups, more handshakes.
• Spriting and bundling: glue many small images or scripts into one file to reduce request count.

All of these are hacks around a protocol limitation — and they actively hurt under HTTP/2.

9. HTTP/2: multiplexing over one connection

HTTP/2 (2015) keeps HTTP's semantics (methods, headers, status codes) but changes how they travel:

• Binary framing: messages are split into small frames, each labelled with a stream ID.
• Multiplexing: many requests and responses (streams) are interleaved on one TCP connection. The 30 thumbnails of a profile grid can all be in flight at once; a slow response no longer blocks the others at the HTTP layer.
• Header compression (HPACK): headers such as cookies, user-agent and auth tokens repeat on every request (often 500–1,000+ bytes). HPACK keeps a table of previously sent headers on both sides and sends small indexes instead — commonly shrinking headers by 80–90%. On a slow uplink, that's a real saving.
• Prioritisation: clients can hint which streams matter more (the on-screen image before a prefetch).
• Server push: the server could send resources before they were requested. It proved hard to use well and major browsers have since removed support — mention it only as history.

The remaining problem: HTTP/2 still runs over TCP, which delivers one ordered byte stream. If a single packet is lost, TCP holds back all later bytes — belonging to all streams — until the retransmission arrives. On a lossy mobile network, HTTP/2's one-connection design can actually suffer more than HTTP/1.1's six connections. This is transport-level head-of-line blocking, and it's what HTTP/3 fixes.

10. HTTP/3 and QUIC: built for mobile

QUIC is a transport protocol originally developed at Google and standardised by the IETF in 2021 (RFC 9000); HTTP/3 is HTTP mapped onto QUIC. QUIC runs over UDP — not because it wants to be unreliable, but because UDP passes through existing routers, NATs and firewalls, letting QUIC implement its own reliable transport in user space instead of inside the OS kernel. That means it can evolve with an app update rather than waiting years for operating systems to change.

10.1 What QUIC changes

• Combined handshake: transport setup and TLS 1.3 happen together — 1 RTT for a new connection instead of 2–3 for TCP + TLS.
• 0-RTT resumption: returning clients can send the request in the first packet (with the replay caveats above).
• Independent streams: reliability and ordering are per stream, so a lost packet only stalls the stream it belongs to — no transport-level head-of-line blocking.
• Connection migration: TCP connections are identified by the 5-tuple, so when your phone moves from Wi-Fi to 4G (new IP address), every TCP connection breaks and must re-handshake. QUIC identifies connections by a connection ID instead, so the same connection continues across the network switch — a video keeps playing as you walk out of your house.
• Always encrypted, including most transport headers, which also stops middleboxes from ossifying the protocol.
• Better loss recovery: unambiguous packet numbers and richer ACKs make retransmission decisions more accurate; congestion control is pluggable (e.g. BBR).

Costs: QUIC uses more CPU per byte than kernel TCP (encryption of every packet, user-space processing), some corporate networks block UDP 443 (so clients must fall back to TCP — typically racing both, "happy eyeballs" style, or remembering what worked), and L4 load balancers must route by connection ID rather than the 5-tuple to support migration.

11. Latency math: what a request really costs

11.1 The physics

Light in optical fibre travels at about 200,000 km/s (two-thirds of its speed in vacuum). So:

one-way delay ≈ 5 µs per km   →   1 ms per 200 km
round trip (RTT) ≈ 1 ms per 100 km of distance   (theoretical floor)

Mumbai → US East (Virginia): ~13,000 km great-circle
  floor RTT = 2 × 13,000 km / 200,000 km/s = 130 ms
  real cables detour (via Europe or Asia-Pacific), plus router hops and queues
  → assume a measured RTT of ~220 ms

No amount of engineering beats the speed of light. You can only (1) reduce the number of round trips or (2) reduce the distance each round trip travels, by moving servers (or at least the connection endpoint) closer to the user.

11.2 Worked example: the first request from Mumbai to a US data center

Assume a user in Mumbai on a good fibre/Wi-Fi connection opens the app and fetches a 60 KB (compressed) feed response. Assume: the DNS answer is cached at a nearby ISP resolver (20 ms), RTT to the US data center is 220 ms, RTT to an Instagram edge PoP in Mumbai is 15 ms, the server takes 50 ms to build the response, and TCP's initial window is ~14 KB (so 60 KB needs the first window plus 2 more RTTs of slow start: 14 + 28 + 56 ≥ 60).

Lessons from the numbers:

• In case A, the server's own 50 ms is under 4% of the total. Round trips, not server time, dominate a cold request over long distances.
• Protocol upgrades (A → B → C → D) cut 200–650 ms by removing round trips.
• Terminating connections near the user (E) is the biggest single win: the handshakes and slow-start ramp happen over a 15 ms path, and only one round trip crosses the ocean — over a long-lived, pre-warmed connection the edge keeps open to the data center. This is why Meta, Google and CDNs run edge PoPs (Meta's edge runs Proxygen) even for uncacheable API traffic. See CDN.
• On a reused warm connection, a follow-up request directly to the US costs only ~220 + 50 = 270 ms — so connection reuse matters as much as anything (see Clients).
• On 4G, add the radio's own latency (assume +30–80 ms per round trip), which multiplies across every RTT above — another reason to minimise round trips.
• To get below ~100 ms you need the data close to the user too: cached media at the CDN, or a regional data center serving India (see Multi-region).

11.3 Latency vs bandwidth

Bandwidth is how wide the pipe is; latency is how long it is. For the small requests that dominate API traffic (a few KB), latency dominates: doubling bandwidth from 50 to 100 Mbps changes almost nothing for a 5 KB request, while halving the RTT nearly halves its time. For big transfers (a 50 MB video upload), bandwidth dominates. The bandwidth-delay product (bandwidth × RTT) tells you how many bytes must be in flight to fill the pipe: 100 Mbps × 0.22 s ≈ 2.75 MB — far more than a fresh connection's 14 KB window, which is why long-distance transfers take many RTTs to reach full speed.

12. Forward proxies vs reverse proxies

A proxy is an intermediary that receives a request and makes it again on someone's behalf. The key question is: on whose behalf?

In Instagram's diagram, every box between the client and the services is a reverse proxy: the CDN edge, the load balancer and the API gateway. Each terminates a connection from the previous hop and opens (or reuses) one to the next. A practical consequence: the backend sees the proxy's IP, not the user's, so proxies add headers like X-Forwarded-For (or the standard Forwarded) carrying the original client IP — needed for rate limiting, abuse detection and geo features. Only trust those headers when set by your own proxies.

Forward proxies matter to Instagram mainly as a fact of life: users behind corporate proxies and middleboxes, which may block UDP (forcing a QUIC → TCP fallback) or interfere with long-lived connections.

13. Real-time on the web: long polling, SSE and WebSockets

HTTP's request/response model has a limitation: the server can only answer, never speak first. Features like DMs, typing indicators, live comments and "new posts" banners need the server to push data when something happens. Three techniques build that on top of HTTP-era infrastructure:

• Long polling: the client sends a request; the server holds it open until there is news (or ~30–60 s pass), then responds; the client immediately sends the next request. Works everywhere, but each message costs a full request/response, and there's a gap while reconnecting.
• Server-Sent Events (SSE): one long-lived HTTP response that the server keeps streaming events into (Content-Type: text/event-stream). Simple, works through most proxies, auto-reconnects in browsers — but one-directional (server → client). Popular for live feeds, notifications and streaming AI responses.
• WebSockets: start as an HTTP request with an Upgrade: websocket header; the server replies 101 Switching Protocols, and the same TCP connection becomes a full-duplex message channel. Either side can send small framed messages at any time with a few bytes of overhead.

GET /chat HTTP/1.1
Host: edge-chat.instagram.example
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
… from here on: binary/text frames in both directions …

Persistent connections shift the scaling problem: instead of many short requests, servers must hold millions of mostly idle connections, send heartbeats to keep NAT mappings alive, and route a message to whichever server holds the recipient's connection. That's the core of Direct messaging; protocol selection is compared in API design, and load-balancing long-lived connections is covered in Load balancing. On mobile, Meta has publicly described using MQTT — a lightweight publish/subscribe protocol designed for unreliable networks — over persistent connections for its messaging features.

14. How Instagram uses all of this

Put the pieces together for one feed load and one image, following the arrows of the main diagram:

1. DNS resolves the API hostname to a nearby edge PoP's (often anycast) address — see DNS.
2. The app opens one QUIC connection (falling back to TCP + TLS 1.3 if UDP is blocked) and keeps it alive for the whole session; all API calls are multiplexed over it.
3. The edge PoP terminates QUIC/TLS a few milliseconds from the user, then forwards the request over long-lived connections on Meta's private backbone to a data center region — so only one long round trip is paid per request.
4. Inside the data center, the load balancer tiers and the API gateway route to the Feed service; internal calls use HTTP/2-based RPC with pooled connections.
5. The JSON response contains CDN URLs; the app fetches images and video segments over a separate, also-reused connection to the CDN hostname — usually served straight from the PoP's cache. See CDN.
6. For DMs and live updates, the app keeps a separate persistent connection (MQTT-style) with periodic heartbeats; in the background, notifications arrive through APNs/FCM.

Rough numbers

Assume 500M DAU × 50 API requests/day = 25 billion requests/day ≈ 290K QPS average (~600K peak)
If each request opened a NEW connection with TCP + TLS 1.2 (3 extra RTTs at ~100 ms average RTT):
   wasted user time = 25B × 300 ms ≈ 7.5 billion seconds/day ≈ 240 user-years per day
   plus ~290K TLS handshakes/s of server CPU
With one long-lived QUIC connection per session (~10 sessions/user/day):
   handshakes drop to 5B/day ≈ 58K/s, most of them 0-RTT resumptions.

15. Trade-offs & common pitfalls

Common pitfalls

• Ignoring round trips: optimising server time from 50 to 30 ms while the client pays 1,000 ms of handshakes.
• Creating a new HTTP client per request in app or service code, defeating connection pooling.
• Keeping HTTP/1.1-era hacks (domain sharding, sprites) after moving to HTTP/2 — they add connections and DNS lookups and break multiplexing benefits.
• Retrying non-idempotent requests blindly after a timeout (duplicate comments, double posts).
• No heartbeats on long-lived connections: NATs and load balancers silently drop idle connections; messages vanish.
• Trusting X-Forwarded-For from the internet: anyone can set it; only accept it from your own proxies.
• Treating 4xx as retryable (hammering the server with the same invalid request) or 5xx/429 as permanent.
• Huge cookies/headers sent on every request — even compressed, they cost bytes on the first request of every connection.

16. Real-world technologies

17. Interview corner

18. Check your understanding

Related lessons

• DNS — the lookup that precedes every new connection, and the 2021 BGP/DNS outage
• CDN — edge PoPs that shorten round trips for media and terminate TLS
• Load balancing — L4 vs L7, TLS termination and long-lived connections
• API gateway — the reverse proxy that authenticates and routes API calls
• Clients — connection reuse, batching and retries on the device
• API design — REST vs gRPC vs GraphQL vs WebSockets, idempotency keys
• Direct messaging — WebSockets/MQTT at scale
• Security — TLS everywhere, mTLS and DDoS protection
• Resilience patterns — timeouts, retries and backoff