Chapter 1 — Complete Notes

How the Internet Works · Backend Perspective

System Design Mastery Program

What you will find in these notes:

• Full concept notes for all 7 topics in Chapter 1

• Follow-up deep-dives: HTTP/2 vs HTTP/3 · TLS internals
• Back-of-envelope estimation framework + 3 worked examples
• Complete Chapter 1 Quiz — questions, model answers, scores
 SECTION 1 — CONCEPT NOTES
■ Concept 1 · DNS — The Internet's Address Book
DNS translates human-readable domain names ([Link]) into IP addresses ([Link]) that computers use to
route traffic.

DNS Resolution Flow

Browser cache
→ OS cache (/etc/hosts)
→ Recursive Resolver (ISP / [Link])
→ Root Nameserver ("who handles .com?")
→ TLD Nameserver (.com)
→ Authoritative Nameserver → returns IP
→ Resolver caches (TTL) → returns to browser

TTL — Critical for Operations

Migration Rule (never forget this):

• Lower TTL to ~300s AT LEAST current-TTL seconds before changing IP

• Change IP after old TTL has fully expired across all resolvers
• Confirm stable, then raise TTL back to 86400s
Why: Some clients cache the record just before you lower TTL — they hold it for the full old duration.

DNS Record Types

Record Purpose Example

A Domain → IPv4 [Link] → 142.x.x.x

AAAA Domain → IPv6 [Link] → 2607:f8b0::...

CNAME Alias to domain www → [Link]

MX Mail server Points to Gmail servers

TXT Verification / SPF Domain ownership proof

• DNS Load Balancing: One domain can return multiple IPs; browser picks first. Simplest LB form — used by Google,
Netflix.
• Netflix example: Route 53 + Eureka → routes to nearest DC, auto-failover on region outage.

■ Concept 2 · TCP/IP — Reliable Delivery

3-Way Handshake
Client → Server : SYN "I want to connect"
Server → Client : SYN-ACK "I am ready"
Client → Server : ACK "Let's go"
■■■■■■ DATA FLOWS ■■■■■■

TCP vs UDP
Property TCP UDP

Reliability ✓ Guaranteed ✗ Best-effort

Ordering ✓ In-order ✗ May be out-of-order

Speed Slower Faster

Connection Required (handshake) Connectionless

Use cases APIs, DB, file transfer Video calls, DNS, gaming

System Design Mastery — Chapter 1 Notes Page 2

 Key TCP Internals
• Congestion Control: TCP auto-slows on congestion. Algorithms: CUBIC, BBR (Google).
• Flow Control (Sliding Window): Sends a window of packets before waiting for ACK. Bigger window = higher
throughput.
• TIME_WAIT: Socket held ~4 min after close. At scale, can exhaust all 65,535 ports — tunable via kernel params.
• Connection Pooling solves repeated handshake cost in production.

■ Concept 3 · HTTP Evolution & HOL Blocking

Feature HTTP/1.1 HTTP/2 HTTP/3 (QUIC)

Transport TCP TCP UDP (QUIC)

Multiplexing ✗ ✓ Streams ✓ Streams

Header compression ✗ ✓ HPACK ✓ QPACK

HOL blocking App + TCP TCP level only ✓ Fully solved

Connection setup 1 RTT + TLS 1 RTT + TLS 1 RTT / 0-RTT

Connection migrate ✗ ✗ ✓ (conn ID)

HOL Blocking — The Key Nuance (common interview trap):

• HTTP/2 multiplexes streams but runs on ONE TCP connection

• If any TCP packet is lost → ALL streams freeze (TCP orders bytes globally)
• HTTP/3 QUIC: each stream is independent at transport layer
• One lost QUIC packet → only THAT stream retransmits; others continue

• HTTP/2 also added: HPACK header compression (saves 30-90%), Server Push, Stream Prioritization.
• QUIC bonus: Connection Migration — IP can change (WiFi → LTE), connection survives via Connection ID.

■ Concept 4 · TLS — Encrypted Transport

TCP vs TLS — what each provides:

TCP = reliable road. TLS = armoured vehicle on that road. HTTP = language inside the vehicle.

• TCP provides: reliable delivery, ordering

• TLS adds: Confidentiality (AES encryption) + Integrity (HMAC) + Authentication (certificates)

TLS 1.3 Handshake Flow

RTT 1:
Client → Server: ClientHello + DH public key + supported ciphers
Server → Client: ServerHello + DH public key + Certificate
+ CertificateVerify + Finished (already encrypted!)

Both sides independently compute shared secret via Diffie-Hellman:

shared_secret = own_private_key × other_public_key
(Eavesdropper cannot compute — needs one private key)

Session keys (AES) derived from shared secret.

All further traffic is encrypted.

Certificate Authentication — Chain of Trust

• Server cert contains: public key + domain name + validity dates, signed by a CA.
• Browser ships with ~150 trusted CAs (Mozilla, Google, Apple maintain lists).
• Client checks: domain match, expiry, CA trust, revocation (OCSP).

System Design Mastery — Chapter 1 Notes Page 3

 DigiNotar Incident (2011):

CA was hacked; attackers issued fake [Link] certs. All browsers removed DigiNotar from trust lists. Company
went bankrupt. Certificate management is critical infrastructure.

Forward Secrecy
• Each session generates a fresh ephemeral DH key pair — discarded after use.
• Even if server private key stolen later → past sessions cannot be decrypted.
• TLS 1.3 mandates forward secrecy; TLS 1.2 RSA mode did not have it.

TLS Termination in Production

[Client]
| HTTPS (encrypted)
↓
[Load Balancer] ← TLS TERMINATES HERE
| HTTP (plain, inside private VPC)
↓
[App Servers]

• Benefits: App servers save CPU, centralised cert management, LB can inspect headers.
• When NOT to: Zero-trust environments → use mTLS (both sides authenticate) internally.
• mTLS: Both client and server present certificates. Used in microservices (Istio handles automatically).

■ Concept 5 · Full Request Lifecycle

[1] User/App makes API call
[2] DNS resolution → IP address (from cache or full lookup)
[3] TCP 3-way handshake (~1 RTT)
[4] TLS 1.3 handshake (~1 RTT)
[5] HTTP request sent
[6] Load balancer routes to app server
[7] App server: auth → DB query → business logic → response
[8] Response travels back through LB (TLS encrypted)
[9] TCP segments reassembled → rendered

Total typical latency: 50 ms – 500 ms

60% = network (hard to control)
40% = your system (optimisable)

■ Concept 6 · Latency Numbers Every Engineer Must Know

Operation Latency

L1 cache reference 0.5 ns

L2 cache reference 7 ns

RAM access 100 ns

SSD random read (4 KB) 150 µs

Round trip — same datacenter 0.5 ms

DB query (indexed, warm cache) ~1 ms

DB query (cold / complex) 10–100 ms

Round trip — cross-continent ~150 ms

Sequential HDD read (1 MB) ~20 ms

System Design Mastery — Chapter 1 Notes Page 4

 Key takeaways:

• RAM is 200 000× faster than HDD → cache everything possible in memory
• Same-DC RTT is 0.5 ms → microservice calls are NOT free; minimise hops
• Cross-continent = 150 ms → CDNs exist for exactly this reason
• 100 DB calls = 100 ms minimum → N+1 query problem is a real production killer

■ Concept 7 · Back-of-Envelope Estimation

4-Step Framework
Step 1: ASSUMPTIONS — users, activity rate, data size
Step 2: SCALE — DAU → daily requests → data volume
Step 3: RESOURCES — storage / bandwidth / servers
Step 4: CONCLUSIONS — what architecture does this force?

Must-Know Numbers
Item Value

1 day ~100 000 seconds (round from 86 400)

X million req/day ÷ 100 000 = X/10 RPS

1 char (ASCII) 1 byte

1 integer 4 bytes

1 UUID 16 bytes

1 tweet (text+meta) ~1 KB

1 photo (compressed) ~200 KB

1 min video (1080p) ~50 MB

1 min video (360p) ~10 MB

3 Golden Rules

• Round aggressively: 86 400 → 100 000. Precision kills speed.

• State assumptions out loud: interviewers care MORE about reasoning than the final number.
• Drive decisions: 100 K reads/s → need caching. 10 TB/year → distributed storage. Numbers without
conclusions are worthless.

Worked Example — Instagram Storage (1 Year)

DAU = 500 million
Posts/day = 500M × 10% = 50 million
Per post = 200 KB (photo) + 1 KB (metadata) ≈ 200 KB

Storage/day = 50M × 200 KB = 10 TB/day

Storage/year = 10 TB × 365 = 3 650 TB ≈ 3.6 PB

With 3× replication: 3.6 PB × 3 = ~11 PB

With multi-resolution (2×): ~22 PB/year

Read QPS = (50M × 100) ÷ 100 000 = 50 000 reads/sec

Write QPS = 50M ÷ 100 000 = 500 writes/sec

Architectural conclusions:
22 PB → distributed object storage (S3 / Haystack)
50 000 reads/sec → CDN + Redis cache for metadata
500 writes/sec → single DB master sufficient

System Design Mastery — Chapter 1 Notes Page 5

 Thumbnail generation → async queue (not in request path)

System Design Mastery — Chapter 1 Notes Page 6

 SECTION 2 — QUIZ & EVALUATION
Six questions covering all Chapter 1 concepts. Model answers and scores included.

Q1 · DNS · Conceptual

A user reports that after you updated your server's IP address, they are still hitting the old server — even 6 hours
later. What is the most likely cause, and how would you have prevented it?

Model Answer — Score: 9.5 / 10 [9.5/10]

• Root cause: DNS TTL was set higher than 6 hours. Resolvers cached the old IP for that duration.
• Prevention: Lower TTL to ~300 s well before the IP change. Wait at least as long as the current TTL before
switching IPs. Raise TTL again after confirming stability.

Complete migration sequence:

T-24h : Lower TTL to 300s (wait for old 86400s TTL to expire)
T-0 : Change the A record to new IP
T+1h : Verify traffic on new server
T+later: Raise TTL back to 86400s

Q2 · TCP vs UDP · Trade-offs

You are building a video calling app. A colleague suggests TCP for reliability. Would you agree or disagree? Justify
with trade-offs.

Model Answer — Score: 8.5 / 10 [8.5/10]

• Answer: Disagree — use UDP (via RTP).

• Core reason: Video is time-sensitive. A frame arriving 300 ms late is useless — better to drop it.
• TCP problem: On packet loss, TCP retransmits and holds back newer frames until the old one arrives in order.
This causes visible stutter.
• UDP advantage: Lost packets are skipped; newer frames keep flowing.
• Production reality: Apps like Zoom / Google Meet use RTP over UDP, which adds sequence numbers and
timestamps without forcing retransmission.

Q3 · TLS · Security Argument

"We don't need TLS. Our app only transfers non-sensitive data — just product listings and prices. HTTP is fine." —
Agree or disagree?

System Design Mastery — Chapter 1 Notes Page 7

 Model Answer — Score: 7 / 10 [7/10]

• Disagree. Five arguments:

• 1. Integrity: Without TLS, a MITM can modify responses — change prices, inject malicious JS, replace links with
phishing URLs.
• 2. Authentication: No TLS = no way for users to verify they are talking to your server, not an impostor on the
same WiFi.
• 3. Browser trust / SEO: Chrome marks HTTP as "Not Secure". Google penalises HTTP sites in rankings.
• 4. Future risk: Today it's product listings. Tomorrow a dev adds a login form to the same domain — instant
credential-stealing vulnerability.
• 5. Compliance: GDPR, PCI-DSS and most frameworks mandate encryption in transit regardless of data
sensitivity.

Q4 · TLS Termination · Architecture

Your team suggests terminating TLS at the load balancer and sending plain HTTP to backend servers. Is this safe?
Trade-offs? When would you NOT do it?

Model Answer — Score: 9 / 10 [9/10]

• Generally safe when backend servers are inside a private VPC / datacenter (isolated from public internet).
• Benefits: App servers save CPU on crypto; centralised certificate management; LB can inspect headers for
routing.
• When NOT to do it: Zero-trust environments, regulated industries (healthcare, finance), or when an internal
breach is a realistic threat model.
• Alternative: mTLS (Mutual TLS) — both client and server present certificates. Istio service mesh automates this
for microservices.

Q5 · HTTP/2 HOL · Trap Question

"HTTP/2 fully solved the Head-of-Line blocking problem." — Correct or incorrect?

Model Answer — Score: 10 / 10 [10/10]

• Incorrect. HTTP/2 solved application-level HOL via multiplexing (many streams on one connection).
• But: TCP sees the connection as one ordered byte stream. One lost TCP packet freezes ALL HTTP/2 streams
until retransmission — TCP-level HOL blocking remains.
• HTTP/3 (QUIC) fully solves it: Each stream is independent at the transport layer. A lost packet in Stream 3 only
blocks Stream 3; Streams 1, 2, 4 continue uninterrupted.

Q6 · Estimation · Instagram Storage

Estimate storage needed for a photo-sharing app like Instagram for 1 year. (500M DAU, 10% post daily, 200 KB
compressed photo, 1 KB metadata, 100:1 read/write ratio.)

System Design Mastery — Chapter 1 Notes Page 8

 Model Answer — Score: 7 / 10 [7/10]
Posts/day = 500M × 10% = 50 million
Per post = 200 KB + 1 KB ≈ 200 KB
Storage/day = 50M × 200 KB = 10 TB/day ← unit must be TB, not GB
Storage/year = 10 TB × 365 = 3.65 PB

With 3× replication ≈ 11 PB
With multi-resolution (2×) ≈ 22 PB

Read QPS = (50M × 100) ÷ 100 000 = 50 000 /s

Write QPS = 50M ÷ 100 000 = 500 /s

• Common error: 50M × 200 KB = 10 TB/day, NOT 10 GB. Always write units at every step.
• Architectural conclusions (most important part):
• 22 PB → distributed object storage (S3 / Facebook Haystack)
• 50 000 reads/s → CDN for photos + Redis for metadata cache
• 500 writes/s → single DB master is sufficient
• Thumbnail generation → async job queue, not in the request path

■ Chapter 1 Quiz — Final Scorecard

Question Score Grade

Q1 — DNS TTL migration 9.5 / 10 ✓

Q2 — TCP vs UDP (video call) 8.5 / 10 ✓

Q3 — TLS for non-sensitive data 7.0 / 10 ~

Q4 — TLS termination at LB 9.0 / 10 ✓

Q5 — HTTP/2 HOL blocking (trap) 10 / 10 ✓

Q6 — Instagram estimation 7.0 / 10 ~

Overall: 51 / 60 = 85% — STRONG PASS ✓

Strong areas:

• DNS operational thinking · Protocol trade-offs · HTTP/2 vs HTTP/3 nuance · TLS termination

Areas to watch:

• Unit conversions in estimation: write units at every multiplication step.

• BOE conclusions: always end with "therefore we need X" — numbers without decisions are incomplete.
• TLS arguments: go beyond MITM — add integrity, authentication, compliance, SEO.

Ready for Chapter 2 → Latency, Throughput & Performance Mental Models

System Design Mastery — Chapter 1 Notes Page 9