System Design

DNS, CDNs & How the Internet Routes Traffic

Mar 19, 2026·9 min read

You Type a URL

It all starts with a simple action: you type https://example.com/api/users into your browser and hit enter.

In the next ~100-300 milliseconds, your request will traverse multiple systems - DNS resolution, TCP handshakes, CDN edges, load balancers, and finally reach an application server. Each layer has a purpose.

Let's follow the packet.

Step 1 - DNS Resolution

Your browser doesn't know what example.com is. It needs an IP address like 93.184.216.34.

DNS (Domain Name System) is the internet's phone book. It translates human-readable domains into IP addresses through a chain of lookups.

The resolution chain:

Browser cache - checked first, fastest
OS cache - system-level DNS cache
Router cache - your local network
ISP's recursive resolver - does the heavy lifting
Root → TLD → Authoritative - the full chain when nothing is cached

DNS Records & TTL

The authoritative nameserver returns a DNS record. Key types:

ADomain → IPv4 address

AAAADomain → IPv6 address

CNAMEAlias to another domain

MXMail server routing

NSNameserver delegation

Every record has a TTL (Time To Live), which tells resolvers how long to cache the answer. A TTL of 300 means “cache this for 5 minutes.”

This is why DNS changes “take time to propagate” - it's really just caches expiring worldwide.

Step 2 - TCP Handshake

Now that the browser has an IP address, it needs to establish a reliable connection using the TCP three-way handshake.

Three packets bounce between client and server before any data is sent:

1. SYNClient → Server: “I want to connect” (sends a sequence number)

2. SYN-ACKServer → Client: “Got it, I'm ready too” (acknowledges + sends its own sequence number)

3. ACKClient → Server: “Connection established”

This adds one round-trip (~20-50ms) before any HTTP data flows. For HTTPS, a TLS handshake follows to negotiate encryption keys, adding another 1-2 round trips.

This is why Connection: keep-alive exists - reusing TCP connections avoids repeating this overhead.

Step 3 - CDN Edge

With the TCP connection established, the request hits a CDN (Content Delivery Network), a globally distributed network of servers that cache content close to users.

The problem it solves: Your server is in Virginia. A user in Tokyo is 11,000 km away. Even at the speed of light in fiber (~200,000 km/s), physics adds ~70ms per round trip.

Cache HIT:

User → CDN Edge (Tokyo) → Response (~5ms)

Cache MISS:

User → CDN Edge → Origin (Virginia) → Response (~200ms)

CDNs also provide DDoS protection, SSL termination, edge compute, and WAF capabilities - all before traffic ever reaches your origin.

Not every app uses a CDN. Server-side rendered apps (Next.js SSR, Rails), services running in Kubernetes pods, or internal tools may skip this layer entirely. In those cases, the request goes straight from the browser to your origin or load balancer.

Step 4 - API Gateway

For API requests that aren't served from cache, traffic reaches the API Gateway, the front door to your backend services.

Before your application code runs, the gateway handles:

→Authentication - validate JWTs, API keys, OAuth tokens
→Rate limiting - 100 req/min per API key
→Routing - direct to the correct service based on path
→Transformation - reshape requests/responses

This keeps cross-cutting concerns out of your business logic.

Step 5 - Load Balancer & Server Processing

The request is now authenticated and routed. The Load Balancer distributes it across healthy application servers.

Round Robin - 1, 2, 3, 1, 2, 3...

Least Connections - send to the least busy server

IP Hash - same client always hits the same server

The selected server processes your HTTP request - runs the application logic, queries the database, and builds a response. This is usually the only latency most engineers think about and control!

Step 6 - HTTP Response

The server sends an HTTP response back through the same chain: origin → load balancer → gateway → CDN edge → browser.

Along the way, the CDN may cache the response for future requests with proper Cache-Control headers.

# Static assets - cache aggressively

Cache-Control: public, max-age=31536000

# API responses - short cache

Cache-Control: public, max-age=60

# Private data - never cache

Cache-Control: no-store

Step 7 - TCP Teardown

After the data transfer is complete, the TCP connection is closed with a four-way handshake:

1. FINClient → Server: “I'm done sending data”

2. ACKServer → Client: “Got it”

3. FINServer → Client: “I'm done too”

4. ACKClient → Server: “Connection closed”

In practice, modern HTTP uses persistent connections - the TCP connection stays open for multiple requests. HTTP/2 goes further with multiplexing, where many requests share a single connection simultaneously.

All of this - DNS, TCP, TLS, CDN, gateway, LB, processing, and response - happens in roughly 100-300ms. Understanding each layer tells you where to optimize, where to cache, and where things break.