Chapter 09 · Edge
DNS & Network Communication
Follow one request through the system — each component exists because the previous layer hit a limit.
DNS & Network Communication — The Hidden Journey
Before your load balancer ever sees Priya's request, it travels through DNS, TCP, and TLS — layers most engineers forget until latency spikes.
Client
→DNS
→TCP + TLS
→HTTP
When Priya types example.com, her device doesn't know where that lives. It asks a DNS resolver — "what IP address owns this domain?" DNS returns something like 52.14.88.201, and only then can her phone open a connection.
The Full Connection Stack
- 1. DNS lookup (~20ms) — Domain → IP. Cached after first visit. TTL controls how long.
- 2. TCP handshake (~1 RTT) — SYN → SYN-ACK → ACK. Establishes a reliable byte stream.
- 3. TLS handshake (~1–2 RTT) — Encrypts the connection. TLS 1.3 is faster than 1.2.
- 4. HTTP request/response — The actual GET or POST with headers and body.
⚠️ Why This Matters at Scale
Your server might process a request in 5ms, but Priya waits 200ms. The gap is network stack overhead. At 1M users, DNS itself becomes infrastructure — you use GeoDNS to send European users to EU servers and Americans to US servers.
✓ What DNS Gives You
✓ PROHuman-readable addresses — users never type IP addresses.
✓ PROTraffic routing — point different regions to different data centers.
✓ PROFailover — change DNS to redirect away from a dead data center.
⚠ CONPropagation delay — DNS changes aren't instant (TTL caching).
The 200ms mystery solved
In interviews, when someone asks "why is my API slow?", walk through this stack. Often the server is fine — it's DNS + TLS + geographic distance eating the budget.
DNS gets Priya to your front door. But half her screen is images and JavaScript — should every pixel travel across the ocean to Virginia? No. That's what a CDN is for.
2 / 9