System Design Concepts

No fluff — visual, concise, interview-ready

🌐 2 · NETWORKING

OSI Model

7-layer reference model for network communication — know L4 and L7 for interviews

#LayerVisualProtocolSystem Design Relevance
7ApplicationHTTP, gRPC, DNS, SMTPL7 Load Balancers (ALB), API Gateways, WAF
6PresentationTLS/SSL, JSON, ProtobufEncryption, serialization
5SessionWebSocket, RPCConnection management
4Transport1234segmentsTCP, UDP, QUICL4 Load Balancers (NLB), port-based routing
3NetworkIP routingIP, ICMPRouting, subnets, VPCs, BGP
2Data LinkswitchEthernet, ARPMAC addresses, switches
1Physical01101Fiber, copperData center hardware
Why it matters: L4 LB routes by IP+port (fast, no content inspection). L7 LB routes by URL/headers/cookies (smart, can do path-based routing). Most system design discussions happen at L4 and L7.

TCP / UDP

Transport layer — TCP (reliable, ordered) vs UDP (fast, unreliable)

TCP — 3-Way Handshake

💻 Client 🖥️ Server SYN SYN-ACK ACK ✓ Connection established Reliable, ordered, bidirectional

UDP — Fire and Forget

💻 Client 🖥️ Server Request Response Response ✗ lost No handshake — send immediately No guarantee, no ordering, fast

Unicast (TCP)

One-to-One

Broadcast (UDP)

One-to-All

Multicast (UDP)

One-to-Several
TCPUDP
Connection-oriented: 3-way handshake (SYN→SYN-ACK→ACK)Connectionless: Send immediately
Ordered + guaranteed: Retransmits lost packetsBest-effort: No retransmission, may arrive out-of-order
Flow + congestion control: Sliding window, slow startNo flow control — sender controls pace
Guarantees: TCP guarantees ordered, reliable, duplicate-free delivery via sequence numbers, ACKs, and retransmission. UDP guarantees nothing — but that's why it's fast (no overhead).
TCP: Banking, HTTPS, DB connections, email. Ports: 80/443/3306/5432/6379/9092
UDP: Live video, gaming, DNS, VoIP, QUIC (HTTP/3). Ports: 53/123/443(QUIC)
Real-world: Fortnite/Valorant use UDP for player positions (few lost packets OK, low latency critical). QUIC (HTTP/3) — UDP-based with built-in TLS 1.3, 0-RTT resumption. Used by Chrome, YouTube, Cloudflare.

HTTP / HTTPS

Application layer — HTTP (plaintext) vs HTTPS (TLS encrypted)

HTTP — Plaintext

👤 Client 🖥️ Server GET /api/data (plaintext) 200 OK {"password":"abc"} 👁️ ⚠ Anyone on network can read everything

HTTPS — TLS Encrypted

👤 Client 🖥️ Server 🔒 TLS encrypted tunnel GET /api/data · 200 OK 👁️ ✓ Sees only encrypted gibberish
▸ How HTTPS Works — TLS Handshake
Client ↔ Server 1 TCP TCP SYN TCP SYN+ACK TCP ACK connection established Asymmetric Encryption 2 Cert Client Hello (supported ciphers, random) Server Hello + Certificate + Server Hello Done Encrypted Session Key 3 Key Client Key Exchange (pre-master secret) Change Cipher Spec + Finished Change Cipher Spec + Finished Session Key 🔑 4 Data 🔒 Symmetric encryption (AES-256) using session key Encrypted Data ↔ Encrypted Data Symmetric Encryption Asymmetric (slow) for key exchange → Symmetric (fast) for data TLS 1.3: 1-RTT handshake · 0-RTT resumption · ECDHE for forward secrecy
MethodPurposeIdempotentSafeCacheable
GETRetrieve✓✓✓
POSTCreate✗✗✗
PUTReplace✓✗✗
PATCHPartial update✗✗✗
DELETERemove✓✗✗
HTTPS Guarantees: Confidentiality (AES-256 encryption) · Integrity (SHA-256 HMAC, tamper-proof) · Authenticity (CA-signed certificate proves server identity) · Forward secrecy (ECDHE — past sessions safe even if key leaked).
2xx — Success
200OK201Created202Accepted (async)
204No Content206Partial Content (streaming)
3xx — Redirect
301Moved Permanently302Found (temp redirect)304Not Modified (cache)
307Temp Redirect (keep method)308Perm Redirect (keep method)
4xx — Client Error
400Bad Request401Unauthorized403Forbidden
404Not Found405Method Not Allowed408Request Timeout
409Conflict410Gone (deleted)413Payload Too Large
415Unsupported Media Type422Unprocessable Entity429Too Many Requests
451Unavailable For Legal Reasons
5xx — Server Error
500Internal Server Error501Not Implemented502Bad Gateway
503Service Unavailable504Gateway Timeout
HTTP/2: Binary framing, multiplexing, header compression (HPACK), server push. HTTP/3: QUIC-based (UDP), no head-of-line blocking, 0-RTT.
HTTP/1.1 vs 2 vs 3: HTTP/1.1 — one request per TCP connection (or pipelining, rarely used). HTTP/2 — multiplexed streams over single TCP, but TCP head-of-line blocking remains (1 lost packet stalls all streams). HTTP/3 (QUIC) — each stream independent over UDP, lost packet only stalls its own stream. 0-RTT resumption — reconnect without handshake (TLS 1.3 session tickets). Adopted by Chrome, YouTube, Cloudflare, Meta.

DNS

Translates domains → IP addresses. The internet's phone book — hierarchical, cached, eventually consistent.

▸ DNS Resolution — Full Lookup Path
Browser local cache OS Resolver /etc/hosts Recursive Resolver ISP / 1.1.1.1 / 8.8.8.8 caches by TTL Root (13) → .com NS TLD (.com) → example NS Authoritative → 93.184.216.34 A record + TTL DNS Routing Policies Simple — single IP Weighted — 70/30 split (canary) Latency — nearest region Geolocation — country-based Failover — health-check based Multivalue — return multiple IPs GeoDNS + Anycast = global LB Full resolution: ~50-200ms (uncached) | Cached: 0ms (browser) to ~1ms (resolver)
RecordPurposeExampleTTL Guidance
A / AAAADomain → IPv4 / IPv6example.com → 93.184.216.34300s (failover) to 86400s (stable)
CNAMEAlias to another domainwww → example.comCan't coexist with other records at apex
ALIAS / ANAMECNAME at zone apexexample.com → cdn.provider.comProvider-specific (Route 53, Cloudflare)
MXMail routing (priority)10 mail.example.com3600s typical
TXTVerification, SPF, DKIMv=spf1 include:_spf.google.com3600s
SRVService discovery (port + weight)_http._tcp.example.com 8080Used by Consul, K8s
NSDelegate to nameserversns1.example.com86400s (rarely changes)
CAAWhich CAs can issue certs0 issue "letsencrypt.org"Security: restrict cert issuance
TTL strategy: Low TTL (60s) = fast failover, higher query load, good for active-passive DR. High TTL (86400s) = less load, slow propagation, good for stable records. Pre-lower TTL before migrations (drop to 60s 24h before cutover).
Real-world: Route 53 — GeoDNS + health checks for multi-region failover. Cloudflare — 1.1.1.1 resolves in ~11ms globally. Anycast — same IP announced from multiple PoPs (nearest wins). DNSSEC — cryptographic chain of trust preventing DNS spoofing.
Anti-patterns: High TTL before migration — users stuck on old IP for hours. CNAME at apex — breaks MX/NS records. No health checks — DNS routes to dead servers. Relying on DNS for sub-second failover — TTL caching prevents it.

IP & CIDR

Address space, subnet sizing, and private ranges — CIDR suffix = network bits, smaller suffix = bigger block

10.0.0.0/8 — 16.7M addresses (entire org) /16 (65K) 10.0.0.0/16 — 65,536 addresses (VPC per region) /24 (256) 10.0.0.0/24 — 256 addresses (subnet per AZ) /28 (16) Rule: suffix +1 = half the block | /24 → /25 = 128 hosts each AWS reserves 5 IPs per subnet (network, router, DNS, future, broadcast)
CIDRHostsTypical UseSubnet Mask
/321Single host (allow-list a server)255.255.255.255
/2816Small subnet (NAT GW, bastion)255.255.255.240
/24256Standard subnet (one AZ)255.255.255.0
/204,096Large subnet (K8s pod CIDR)255.255.240.0
/1665,536VPC per region255.255.0.0
/816.7MEntire org (10.0.0.0/8)255.0.0.0
Private ranges (RFC 1918): 10.0.0.0/8 · 172.16.0.0/12 · 192.168.0.0/16. Used inside VPCs; not routable on public internet. Plan CIDR carefully — VPC peering requires non-overlapping ranges.
VPC design: Use /16 per VPC, split into /24 subnets per AZ. Separate public (LB), private (app), and isolated (DB) subnets. Leave room for growth — you can't resize a VPC CIDR easily.
Anti-patterns: Overlapping CIDRs — can't peer VPCs. Too small VPC — run out of IPs when scaling. /16 subnets — waste addresses, broadcast domain too large. Using 172.17.0.0/16 — conflicts with Docker default bridge.

Key Ports Cheat Sheet

Standard ports you'll meet in any architecture diagram — ports < 1024 are privileged (need root)

PortServiceProtocolSecurity Notes
22SSHTCPKey-based auth only, disable password login
53DNSUDP/TCPUDP first, TCP for > 512B or zone transfers
80HTTPTCPRedirect to 443, never serve sensitive data
443HTTPSTCPTLS 1.3, HSTS header, cert pinning for mobile
3306MySQLTCPPrivate subnet only, never expose publicly
5432PostgreSQLTCPSSL mode = require, restrict to app CIDR
6379RedisTCPNo auth by default — always set requirepass + ACL
9092KafkaTCP9093 for TLS, SASL for auth
9200ElasticsearchTCPNever expose publicly (data exfil risk)
27017MongoDBTCPEnable auth, bind to private IP only
8080/8443App serversTCPNon-privileged, behind LB on 80/443
2379/2380etcdTCPClient/peer ports, mTLS required
Rule of thumb: Run apps on 8080/8443 (non-privileged) and let a load balancer terminate 80/443. Only expose ports that must be public. Database ports should never be reachable from the internet.
Common breaches: Open Redis (6379) — cryptominer injection. Open Elasticsearch — data exfiltration. Open MongoDB — ransomware. Always scan with nmap or cloud security tools.

Firewalls — Security Groups vs NACLs

Two layers of network filtering in every cloud VPC — defense in depth

▸ VPC Network Security — Layered Filtering
Internet untrusted VPC NACL (Subnet-level) stateless · allow + deny numbered rules, first match coarse: block CIDR ranges Security Group (Instance) stateful · allow only all rules evaluated fine: per-port, per-source SG EC2 / Pod app workload port 8080 Layer 1: subnet perimeter Layer 2: instance perimeter
AspectSecurity GroupNACL
ScopeInstance / ENI (can reference other SGs)Entire subnet
StateStateful — return traffic auto-allowedStateless — must allow both directions explicitly
RulesAllow only (implicit deny all)Allow + Deny (explicit deny possible)
EvaluationAll rules evaluated (most permissive wins)Numbered, first match wins
Use caseFine-grained: "app SG can talk to DB SG on 5432"Coarse: "block this CIDR range entirely"
Limits~60 rules per SG, 5 SGs per ENI20 rules per NACL (soft limit)
Best practice: Least-privilege allow-list per port. Default deny everything. Reference SG-to-SG instead of CIDR (survives IP changes). Use NACLs as a coarse "block this CIDR" knife for known-bad ranges.
K8s equivalent: NetworkPolicy — pod-level firewall (Calico, Cilium). Default deny all ingress/egress, then allow specific label selectors. Service Mesh (Istio) adds L7 policies (allow GET /api but deny POST).
Anti-patterns: 0.0.0.0/0 on DB port — database exposed to internet. Single SG for everything — no isolation between tiers. Overly permissive egress — allows data exfiltration. No logging — can't detect unauthorized access.

Zero Trust Networking

"Never trust, always verify" — no implicit trust for internal traffic. Every request authenticated, authorized, encrypted.

▸ Zero Trust — Every Hop Verified
Service A SPIFFE ID: spiffe://cluster/ns/svc-a short-lived cert (1h) Sidecar Proxy Envoy / Linkerd 🔒 mTLS termination cert rotation (auto) L7 observability mTLS Policy Engine OPA / Istio AuthZ ✓ identity verified ✓ action authorized deny by default Service B SPIFFE ID: spiffe://cluster/ns/svc-b validates caller identity Zero Trust Pillars ① Verify identity (mTLS/JWT) ② Verify device posture ③ Least privilege access ④ Encrypt everything ⑤ Log + audit all access ⑥ Assume breach ⑦ Micro-segmentation ⑧ Continuous verification Network location ≠ trust. Internal traffic is treated same as external. Result: lateral movement blocked even if one service is compromised
ComponentPurposeTools
Service IdentityCryptographic identity per workloadSPIFFE/SPIRE, K8s ServiceAccount, AWS IAM Roles
mTLSMutual authentication + encryptionIstio, Linkerd, Consul Connect, Cilium
Policy EngineFine-grained authorization (who can call what)OPA/Rego, Istio AuthorizationPolicy, Cedar
Cert ManagementAuto-rotate short-lived certificatescert-manager, Vault PKI, SPIRE
BeyondCorp ProxyIdentity-aware access for humansCloudflare Access, Google IAP, Zscaler
ObservabilityAudit all access decisionsEnvoy access logs, OPA decision logs
Implementation: Istio/Linkerd — inject sidecar proxy, auto-mTLS between all pods. SPIFFE — universal workload identity (x509 SVIDs). OPA — "svc-a can call svc-b GET /api/orders but not DELETE". Short-lived certs (1h) — compromised cert expires quickly.
Real-world: Google BeyondCorp — no VPN, all access through identity-aware proxy. Netflix — mTLS everywhere via custom CA. Airbnb — SPIFFE for service identity. Cloudflare — Access replaces VPN for employee access.
Anti-patterns: VPN = trusted — once inside VPN, full access (flat network). IP-based allow-lists — IPs change, can be spoofed. Long-lived certs — compromised cert valid for years. No east-west encryption — internal traffic sniffable.

DDoS Defense

Layers of mitigation from edge to origin — absorb volumetric attacks, filter application-layer floods

▸ DDoS Defense — Multi-Layer Protection
Attackers ↯ 100 Gbps botnet flood ① Anycast Edge absorb volumetric 300+ PoPs globally 100+ Tbps capacity Cloudflare / AWS Shield BGP blackhole for L3 ② WAF L7 filtering rate-limit per IP/JA3 geo-block, IP reputation OWASP rules (SQLi, XSS) custom rules per endpoint ③ Bot Mgmt CAPTCHA / JS challenge browser fingerprinting ML anomaly detection device attestation behavioral analysis ④ App Layer auto-scaling circuit breakers graceful degradation queue-based admission signed cookies/tokens ✓ Origin (clean traffic) drops 95% volumetric blocks 90% L7 attacks filters 99% bots handles remaining load Capacity rule: edge must absorb 10-100× your peak legitimate traffic
LayerAttack TypeDefenseTools
L3/L4 (Network)SYN flood, UDP amplification, ICMP floodAnycast absorption, scrubbing centers, BGP blackholeCloudflare Magic Transit, AWS Shield Advanced
L7 (Application)HTTP flood, slowloris, cache-bustingWAF rules, rate-limit per IP/JA3/path, geo-blockCloudflare WAF, AWS WAF, Akamai Kona
Bot / CredentialCredential stuffing, scraping, account takeoverCAPTCHA, device fingerprint, behavioral MLCloudflare Bot Mgmt, PerimeterX, DataDome
DNSDNS amplification, NXDOMAIN floodAnycast DNS, rate-limit queries, DNSSECRoute 53 Shield, Cloudflare DNS
APIAPI abuse, enumeration, resource exhaustionAPI gateway rate-limit, token bucket, signed requestsKong, Apigee, AWS API Gateway
▸ DDoS Attack Types & Signatures

Volumetric (L3/L4)

  • SYN flood: exhaust connection table
  • UDP amplification: DNS/NTP/memcached reflection
  • ICMP flood: saturate bandwidth
  • Scale: 1-3 Tbps (record attacks)
  • Defense: absorb at edge, can't filter at app

Application (L7)

  • HTTP flood: legitimate-looking requests at scale
  • Slowloris: hold connections open slowly
  • Cache-busting: unique URLs bypass CDN
  • Scale: 10K-10M RPS
  • Defense: WAF, rate-limit, CAPTCHA, behavioral
Defense-in-depth: Edge (Cloudflare/Shield) absorbs volumetric → WAF filters L7 → Rate limiting per IP/path → Bot management challenges suspicious → App gracefully degrades under remaining load. Each layer reduces attack surface for the next.
Preparation: Always-on protection (not on-demand — too slow to activate). Runbook for escalation. Load test your own infrastructure to know breaking points. Separate static assets on CDN (attackers can't exhaust origin for static content).
Anti-patterns: No edge protection — origin directly exposed. On-demand only — takes 10+ min to activate during attack. Single-region — no geographic distribution to absorb. Exposing origin IP — attackers bypass CDN directly.
Real-world: Cloudflare — mitigated 71M RPS attack (2023). AWS Shield Advanced — auto-mitigates with DDoS Response Team. Google Cloud Armor — adaptive protection with ML. GitHub — survived 1.35 Tbps memcached amplification (2018).