System Design Networking: DNS, CDNs, and Load Balancers

Scenario context

When you hit a URL, DNS translates the name to an IP, CDNs serve static assets from the edge nearest to you, and Load Balancers spread traffic across many servers so no single machine becomes a bottleneck. These three layers are the traffic control system of the modern internet.

In 2021, GitHub went dark for nearly two hours. The cause was a misconfigured BGP route that blackholed traffic to GitHub…

This walkthrough focuses on Three Layers That Stand Between a User and Your Server.

Before making a design choice, clarify:

• In 2021, GitHub went dark for nearly two hours.
• The cause was a misconfigured BGP route that blackholed traffic to GitHub's DNS servers — meaning no request could resolve github.com to an IP address at all, let alone reach an application server.
• The outage was not a code bug or a database crash; it was a failure in the three infrastructure layers that execute before your application code ever runs.

Concepts in play: caching, system-design-hld-architectures, load-balancing, jvm-internals-and-garbage-collection

Stage 1 — The Building Blocks: What Each Component Does

• Every web request to your application routes through three core network layers before reaching your code.
• DNS (Domain Name System) is the phone book of the internet: it translates human-readable hostnames like api.example.com into machine-readable IP addresses.
• Without DNS, users would need to memorize IP addresses directly to reach your service.
• CDN (Content Delivery Network) is a distributed cache of static assets.

Observable outcome: CDN (Content Delivery Network) is a distributed cache of static assets.

Stage 2 — DNS: The Internet's Phone Book

• DNS maps example.com → 192.0.2.1 .
• The resolution chain has four hops: 1.
• Recursive resolver (usually your ISP or 8.8.8.8) receives the query.
• Root server directs to the TLD server.

sequenceDiagram
    participant B as Browser
    participant OS as OS Cache
    participant RR as Recursive Resolver
    participant Root as Root NS (.)
    participant TLD as TLD NS (.com)
    participant Auth as Authoritative NS

    B->>OS: Resolve api.example.com
    OS-->>B: Cache miss
    B->>RR: Query api.example.com
    RR->>Root: Where is .com?
    Root-->>RR: TLD NS address for .com
    RR->>TLD: Where is example.com?
    TLD-->>RR: Auth NS for example.com
    RR->>Auth: A record for api.example.com?
    Auth-->>RR: 203.0.113.10 (TTL 300s)
    RR-->>B: 203.0.113.10 (cached per TTL)

Observable outcome: Root server directs to the TLD server.

Stage 3 — CDNs: Bringing Content Closer to Users

• A CDN is a globally distributed cache.
• When a user requests /static/logo.png , the CDN serves it from an edge PoP (Point of Presence) in their city rather than your origin server in a distant datacenter.
• CDN hit ratio is the fraction of requests served from cache: $$ ext{Avg Latency} = r \cdot L ext{edge} + (1 - r) \cdot L ext{origin}$$ where $r$ is the hit ratio.
• Even improving $r$ from 0.80 to 0.95 dramatically reduces effective latency.

Observable outcome: Even improving $r$ from 0.80 to 0.95 dramatically reduces effective latency.

Stage 4 — Load Balancers: Distributing Traffic Intelligently

• A load balancer sits in front of your server pool and routes incoming requests: Layer 4 vs Layer 7: Routing algorithms: Health checks probe each backend (HTTP /health , TCP ping) on a configurable interval.
• Unhealthy servers are removed from rotation without human intervention.
• Load imbalance metric: $$ ext{Imbalance} = rac{\max( ext{server QPS})}{ ext{avg}( ext{server QPS})}$$ A ratio near 1.0 means excellent distribution; above 2.0 is a warning sign.
• 📊 CDN Cache Miss and Hit Flow This sequence diagram contrasts a CDN cache miss on the first request with a cache hit on the second request for the same static asset.

flowchart TD
    A[User Browser] -->|DNS lookup returns LB IP| B[Load Balancer L7]
    B -->|Route /api| C[App Server 1]
    B -->|Route /api| D[App Server 2]
    B -->|Route /static| E[CDN Edge Node]
    C --> F[Origin DB]
    D --> F

sequenceDiagram
    participant C as Client
    participant E as CDN Edge PoP
    participant O as Origin Server

    C->>E: GET /static/logo.png
    Note over E: Cache MISS (first request)
    E->>O: Forward to origin
    O-->>E: 200 OK + logo.png payload
    E-->>C: 200 OK (served + cached at edge)
    Note over E: Cached for max-age=86400s

    C->>E: GET /static/logo.png
    Note over E: Cache HIT
    E-->>C: 200 OK (from edge, ~5ms)
    Note over O: Origin not contacted on hit

Observable outcome: 📊 CDN Cache Miss and Hit Flow This sequence diagram contrasts a CDN cache miss on the first request with a cache hit on the second request for the same static asset.

Stage 5 — Deep Dive: Inside a DNS Resolution and Cache Lifecycle

• When you type a URL, the OS checks its local DNS cache first.
• On a miss, the query travels to a recursive resolver, which fans out to root → TLD → authoritative nameserver.
• Each hop adds a few milliseconds — but the result is cached per TTL, so repeat visits skip all hops.
• This is why TTL tuning matters: a 24-hour TTL means stale IPs persist for 24 hours after a server change.

Observable outcome: This is why TTL tuning matters: a 24-hour TTL means stale IPs persist for 24 hours after a server change.

Stage 6 — The Full Request Journey: DNS → CDN → Load Balancer → App

• This diagram shows how a single user interaction splits into two parallel paths: the API request travels through DNS resolution to the load balancer and then to an app server, while the static asset request is intercept…
• Notice that the CDN request never touches the load balancer or app server — this is the core value proposition of a CDN, removing an entire class of requests from the origin.
• The combined effect of DNS caching, edge caching, and load-balanced app servers is what allows a modest backend cluster to serve millions of users globally.

sequenceDiagram
    participant U as User Browser
    participant R as Recursive Resolver
    participant A as Authoritative NS
    participant LB as Load Balancer
    participant CDN as CDN Edge
    participant App as App Server

    U->>R: Resolve example.com
    R->>A: Query A record
    A-->>R: Returns LB IP
    R-->>U: LB IP (cached per TTL)
    U->>LB: GET /api/data
    LB->>App: Forward request
    App-->>LB: JSON response
    LB-->>U: JSON response
    U->>CDN: GET /static/logo.png
    CDN-->>U: Serve from edge cache

Observable outcome: The combined effect of DNS caching, edge caching, and load-balanced app servers is what allows a modest backend cluster to serve millions of users globally.

End-to-end outcome

In 2021, GitHub went dark for nearly two hours.

Alternatives considered

Decision Guide: When to Use What

Decision Guide: When to Use What

Failure and degraded modes

Trade-offs & Failure Modes

• Detection: Trade-offs & Failure Modes
• User or operator impact: Trade-offs & Failure Modes