How the Internet Works

SLIDE 2: The Life of a Web Request

Section 2: How the Internet Works

Before we design systems, we need to understand how the internet actually moves data between machines. Every system you will ever design whether it’s a chat application, a video platform, or a payment service relies on the same underlying mechanics.

What We’ll Cover:

1. Client-Server Model
2. DNS (Domain Name System)
3. IP Addresses and Ports
4. TCP and UDP
5. HTTP and HTTPS
6. The complete request-response lifecycle
7. Latency and round-trip time

Why This Matters for System Design:

The Key Question:

When you open YouTube on your phone and a video starts playing, what actually happened between you tapping the screen and pixels appearing? That journey involves DNS resolution, TCP connections, TLS handshakes, HTTP requests, load balancers, application servers, databases, CDNs, and object storage every component we’ll cover in this course.

Let’s trace that journey step by step.

SLIDE 3: Client-Server Model

Client-Server Model

The client-server model is the foundation of virtually every networked system. A client is any device or application that initiates a request. A server is any machine that receives that request, processes it, and sends back a response.

Examples of Clients:

• Web browser (Chrome, Safari, Firefox)
• Mobile app (Instagram app, WhatsApp)
• Desktop application (Slack, VS Code)
• Another server (Server A calling Server B’s API)

Examples of Servers:

• Web server (Nginx, Apache) serves static files
• Application server (Node.js, Django, Spring Boot) runs business logic
• Database server (PostgreSQL, MySQL) stores and retrieves data

Key Characteristics:

SLIDE 3B: Client-Server Model (continued)

One Server, Many Clients:

At its simplest, a client-server system looks like this:

This works fine at small scale. But at YouTube’s scale 2.5 billion monthly active users a single server cannot handle the load. This is the fundamental problem that system design solves: how do you serve millions of clients reliably and fast?

What a Single Server Can Handle:

Typical web server capacity:
- 1,000-10,000 concurrent connections
- 500-5,000 requests per second (depending on complexity)
- 8-64 GB RAM
- 1-10 TB storage

YouTube's actual load:
- 500,000+ requests per second
- 500+ hours of video uploaded every minute
- 1 billion hours of video watched per day

A single server handles roughly 0.1% of YouTube's traffic.
The remaining 99.9% is what system design is about.

The Rest of This Course:

Every section builds on this model. Load balancers distribute clients across multiple servers. Databases move data off the application server. Caches reduce database load. CDNs serve content from locations closer to the client. The client-server model doesn’t change it scales.

SLIDE 4: DNS (Domain Name System)

DNS: Domain Name System

When you type youtube.com into your browser, your computer needs to find the IP address of YouTube’s server. Computers communicate using IP addresses (like 142.250.80.46), not human-readable domain names. DNS is the system that translates domain names to IP addresses.

Analogy:

DNS is a phone book. You know a person’s name (youtube.com), but you need their phone number (142.250.80.46) to reach them. DNS performs this lookup.

Input:  youtube.com
Output: 142.250.80.46

Input:  instagram.com
Output: 157.240.1.174

Input:  amazon.com
Output: 205.251.242.103

Why Not Just Use IP Addresses Directly?

DNS Record Types:

SLIDE 4B: DNS Resolution

How DNS Resolution Works:

When your browser needs to resolve youtube.com, it goes through multiple levels of lookup. Each level either has the answer cached or forwards the query to the next level.

Resolution Steps:

1. Browser checks its own cache (did I look this up recently?)
2. OS checks its local DNS cache
3. Query goes to ISP’s recursive resolver
4. Resolver asks Root Name Server → gets directed to .com TLD
5. Resolver asks .com TLD server → gets directed to Google’s authoritative DNS
6. Resolver asks Google’s authoritative DNS → gets the IP address
7. Result cached at every level based on TTL (Time to Live)

SLIDE 4C: DNS in System Design

Why DNS Matters in System Design:

DNS is not just an internet plumbing detail it’s an active component in system architecture.

1. Global Load Balancing (GeoDNS):

2. Failover and High Availability:

3. CDN Integration:

Interview Tip:
If an interviewer asks how you’d handle global traffic distribution or failover, mention DNS-based load balancing as the first layer. It operates before the request even reaches your infrastructure making it the cheapest and simplest form of routing.

Common Misconception:
DNS is not real-time. TTL means changes propagate in minutes to hours, not instantly. Designing for instant failover requires additional layers (load balancers, health checks) DNS alone is insufficient.

SLIDE 5: IP Addresses and Ports

IP Addresses and Ports

Once DNS gives us the IP address of a server, we need two things to establish a connection: the IP address (which machine) and the port number (which application on that machine).

IP Address: The Building Address:

An IP address identifies a specific machine on the internet.

IPv4: 142.250.80.46        (4 bytes, ~4.3 billion addresses)
IPv6: 2607:f8b0:4004:800::200e  (16 bytes, ~340 undecillion addresses)

IPv4 is running out of addresses (4.3 billion < 8 billion people + devices).
IPv6 solves this but adoption is gradual. Most systems support both.

Port Number: The Apartment Number:

A single server runs multiple applications. The port number tells the operating system which application should receive the incoming request.

Putting It Together:

System Design Relevance:

In production, different services run on different ports on the same machine or across machines. When you see architecture diagrams with “PostgreSQL on port 5432” or “Redis on port 6379,” this is why each service listens on its own port.

SLIDE 6: TCP vs UDP

TCP and UDP: Transport Layer Protocols

Once we have the IP address and port, we need a protocol to actually send data between client and server. The two fundamental transport protocols are TCP and UDP. They solve the same problem moving data between two machines but with different guarantees.

TCP (Transmission Control Protocol):

TCP guarantees that data arrives completely, in order, and without corruption. It does this through a connection-oriented approach.

TCP Guarantees:

• Ordered delivery: Packets arrive in the same order they were sent
• Reliable delivery: Lost packets are automatically retransmitted
• Error checking: Corrupted packets are detected and re-requested
• Flow control: Sender slows down if receiver is overwhelmed
• Congestion control: Sender slows down if network is congested

Cost of These Guarantees:

Additional overhead per connection:
- Handshake: 1.5 round trips before data flows (~50-150ms)
- Packet headers: 20 bytes of overhead per packet
- Acknowledgments: Receiver must confirm every packet received
- Retransmission: Lost packets resent, adding latency

For a video call, a retransmitted packet from 2 seconds ago is useless.
The moment has passed the user needs the CURRENT frame, not an old one.

SLIDE 6B: UDP and Protocol Selection

UDP (User Datagram Protocol):

UDP sends data without establishing a connection and without guaranteeing delivery. It’s a “fire and forget” protocol.

UDP Characteristics:

• No connection setup (no handshake data sent immediately)
• No delivery guarantee (packets can be lost)
• No ordering guarantee (packets can arrive out of order)
• No congestion control (sender can flood the network)
• Minimal overhead (8-byte header vs TCP’s 20-byte header)

Where Each Protocol Is Used:

How This Applies to System Design:

In most system design interviews, your services communicate over TCP (HTTP/HTTPS, gRPC, database connections). You would mention UDP specifically when designing:

• Live video or audio streaming systems
• Real-time multiplayer gaming backends
• IoT telemetry ingestion (millions of sensors sending small packets)

The Hybrid Approach:

Modern video streaming (YouTube, Netflix) actually uses TCP for the video data via HTTP-based protocols like HLS and DASH. The video is broken into small chunks (2-10 seconds each), downloaded over TCP, and buffered. This works because the video is pre-recorded a small delay for buffering is acceptable. Live video calls use UDP because there’s no buffer window.

SLIDE 7: HTTP and HTTPS

HTTP: HyperText Transfer Protocol

HTTP is the application-layer protocol that runs on top of TCP. It defines how clients and servers structure their communication what a request looks like, what a response looks like, and what metadata travels with each.

HTTP is a Request-Response Protocol:

Every HTTP interaction follows the same pattern:

1. Client sends a REQUEST
   - Method: What action to perform (GET, POST, PUT, DELETE)
   - URL: Which resource to act on (/videos/abc123)
   - Headers: Metadata (authentication, content type, caching)
   - Body: Data payload (for POST/PUT the content being sent)

2. Server sends a RESPONSE
   - Status Code: What happened (200 OK, 404 Not Found, 500 Error)
   - Headers: Metadata (content type, cache directives, cookies)
   - Body: The actual data (HTML page, JSON data, image bytes)

Example: Loading a YouTube Video Page

REQUEST:
GET /watch?v=dQw4w9WgXcQ HTTP/1.1
Host: youtube.com
Accept: text/html
Authorization: Bearer eyJhbGciOi...
Cookie: session_id=abc123

RESPONSE:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 256000
Cache-Control: no-cache
Set-Cookie: visitor_id=xyz789

<!DOCTYPE html>
<html>
  ... (YouTube video page HTML) ...
</html>

HTTP Versions:

Most production systems today use HTTP/1.1 or HTTP/2. HTTP/3 adoption is growing, particularly at Google and Cloudflare.

SLIDE 8: HTTP Methods

HTTP Methods

Each HTTP method signals a different intent. Using the correct method is not just convention it affects caching behavior, idempotency, and how intermediaries (proxies, CDNs, load balancers) handle the request.

Idempotency Explained:

Why Idempotency Matters in System Design:

Scenario: User clicks "Submit Order" and the network is slow.

If POST /orders is not idempotent:
- User clicks again (impatient)
- Two orders created (duplicate charge)
- Customer support ticket filed

In distributed systems, network failures and retries are common.
Non-idempotent operations need explicit duplicate protection
(idempotency keys, unique request IDs).

This is why payment APIs like Stripe require an idempotency_key
with every POST request.

Common Mistake in Interviews:

Using POST for everything. If an interviewer sees POST /getUser or POST /deletePost in your API design, it signals unfamiliarity with REST conventions. Use the HTTP method to convey the action, and the URL to identify the resource.

SLIDE 9: HTTP Status Codes

HTTP Status Codes

Status codes are grouped into five categories by their first digit. You don’t need to memorize all of them but you should know the ones that come up in every system design discussion.

Categories:

Status Codes You Should Know:

System Design Context:

Interview Tip:
When designing APIs, be specific about which status codes each endpoint returns. Saying “returns 200 on success” is minimum. Saying “returns 201 Created with the resource in the body, 409 Conflict if the username already exists, 429 if rate limited” demonstrates production experience.

SLIDE 10: TLS and Encryption

TLS: Transport Layer Security

HTTPS is HTTP + TLS. TLS encrypts the communication between client and server so that no one in between (ISPs, Wi-Fi operators, attackers) can read or modify the data.

What TLS Protects Against:

TLS Handshake (Simplified):

Performance Cost:

TLS handshake adds latency:
- TLS 1.2: 2 additional round trips (~100-300ms)
- TLS 1.3: 1 additional round trip (~50-150ms)
- TLS 1.3 with 0-RTT resumption: 0 additional round trips (returning visitors)

At scale, this matters:
- YouTube serves billions of requests per day
- Each new connection pays the TLS handshake cost
- HTTP/2 and keep-alive connections reduce this by reusing connections

System Design Relevance:

• All external traffic should be HTTPS (TLS terminated at load balancer or CDN)
• Internal service-to-service traffic within a data center is often unencrypted (performance) or uses mutual TLS (mTLS) in zero-trust environments
• TLS termination at the load balancer means the load balancer decrypts the request, inspects it, and forwards it unencrypted to backend servers this is the most common production pattern

SLIDE 11: Request-Response Lifecycle

Complete Request-Response Lifecycle

Now we can trace a complete HTTP request from start to finish, combining every concept covered so far.

Time Breakdown for a Typical Request:

What Dominates Latency:

At small scale, server processing time dominates. At global scale, network latency (physical distance) dominates. This is why CDNs exist serving content from a server 50km away instead of 10,000km away eliminates hundreds of milliseconds.

SLIDE 12: What Happens When You Type youtube.com

Full Journey: What Happens When You Type youtube.com

This is one of the most common technical interview questions, and it touches every concept we’ve covered. Here’s the complete sequence:

What This Question Tests:

An interviewer asking this question is evaluating whether you understand:

• Networking fundamentals (DNS, TCP, TLS, HTTP)
• Client-server architecture
• Caching at multiple levels (DNS cache, CDN cache, browser cache)
• The role of CDNs in serving static assets
• How a load balancer distributes traffic
• Server-side processing (application logic, database queries)

You don’t need to recite every detail. Focus on the layers: DNS → TCP → TLS → HTTP → Server Processing → Response → Rendering. Then offer to go deeper on any layer the interviewer is interested in.

SLIDE 13: Latency and Round-Trip Time

Latency and Round-Trip Time

Latency is the time it takes for data to travel from one point to another. Round-trip time (RTT) is the time for a request to travel from client to server and the response to return.

Speed of Light Sets the Floor:

Real-World Latency Measurements:

Why This Table Matters for System Design:

Reading from RAM:        100 nanoseconds
Reading from disk:    10,000,000 nanoseconds  (100,000x slower)
Reading from cache:      500,000 nanoseconds  (same data center Redis)

This is why caching works. The speed difference between RAM and disk
is five orders of magnitude. A system that serves data from cache
instead of database is not just "a little faster" it's fundamentally
operating at a different time scale.

Latency Budget Example:

Requirement: YouTube homepage must load in under 500ms (P95)

Budget allocation:
- DNS:                 0ms  (cached)
- TCP + TLS:          50ms  (connection reuse via keep-alive)
- Server processing: 100ms  (application logic + database/cache reads)
- Network transit:   100ms  (server to user, assumes CDN for static assets)
- Browser rendering: 200ms  (parse HTML, load critical CSS/JS)
- Buffer:             50ms

Total: 500ms

If your server processing takes 300ms instead of 100ms,
you've already blown the budget before the browser even starts rendering.
This is why capacity estimation and caching decisions matter.

SLIDE 13B: Latency in System Design Decisions

How Latency Shapes Architecture:

Every major system design decision is, at its core, a latency optimization.

The Latency Hierarchy:

Interview Tip:
When discussing performance in an interview, reference specific latency numbers. Saying “caching makes it faster” is vague. Saying “a Redis cache hit takes ~500 microseconds versus ~10 milliseconds for a database query with an index a 20x improvement” demonstrates quantitative reasoning.

SLIDE 14: Section Summary and Interview Tips

Section 2 Summary: How the Internet Works

Concepts Covered:

How These Concepts Connect to the Rest of This Course:

Section 3 (Servers):     Builds on client-server model what happens inside the server
Section 4 (Databases):   The data layer that servers query (port 5432, 3306, 6379)
Section 5 (Scaling):     Solving the "one server isn't enough" problem from Slide 3B
Section 6 (Caching):     Solving the latency problem RAM vs disk, 100,000x difference
Section 7 (Load Balancing): Distributing TCP connections across multiple servers
Section 8 (CDN):         Solving cross-continent latency with edge servers
Section 9 (Queues):      Async processing don't make clients wait for slow operations
Section 10 (APIs):       Designing HTTP endpoints with proper methods and status codes

Common Interview Mistakes:

• Not knowing the difference between TCP and UDP, or when to use each
• Confusing 401 (not authenticated) with 403 (not authorized)
• Forgetting that DNS resolution adds latency to the first request
• Not considering TLS handshake cost when estimating latency budgets
• Treating latency as a single number instead of a distribution (P50, P95, P99)

Key Numbers to Remember:

- DNS lookup (uncached): 20-100ms
- TCP handshake: 20-50ms
- TLS handshake: 50-150ms (TLS 1.3: 1 round trip)
- Same data center RTT: ~0.5ms
- Same continent RTT: 50-100ms
- Cross-continent RTT: 100-300ms
- RAM access: 100 nanoseconds
- SSD read: 150 microseconds
- HDD read: 10 milliseconds