How a Request Travels

From the click to the response — the classic journey through DNS, the edge, the balancer, the gateway, and the data layer. The system design interview diagram, drawn properly.

You hit Enter GET api.example.com/orders
1
DNS Resolution
Browser / OS Cache
Recursive Resolver
Root → TLD → Authoritative
TTL Caching
TCP 3-way handshake + TLS — often terminated at the edge or balancer
2
CDN / Edge
Edge PoP Nearby
Static Assets
Cache Rules
DDoS / WAF
3
Load Balancer
Round Robin
Least Connections
Health Checks
Failover
4
API Gateway
AuthN / AuthZ
Rate Limiting
Routing
Validation
5
Application Service
Business Logic
Service Calls
Serialization
Observability
6
Cache Layer
Redis / Memcached
Cache-aside
TTL & Eviction
Invalidation
7
Database
Query Planner
Indexes
Read Replicas
Connection Pool
Response 200 OK · application/json

On the way back

Status Code2xx / 3xx / 4xx / 5xx — the one-line verdict
Compressiongzip / brotli shrink the body in transit
Cache HeadersCache-Control & ETag decide who may remember it
RenderBrowser parses, paints, and the user sees it
Journey: DNS → TCP/TLS → CDN → Load Balancer → API Gateway → Service → Cache → Database → back. Real architectures vary — the gateway and balancer are often combined, and either can come first — but this is the shape to reason from.