The Runtime Theory
ServerDSAarchitecture

Trace a Request Through a Load-Balanced Service

Follow a request from DNS through the load balancer, health-checked backend selection, cache lookup, and database miss or hit.

The Runtime Theory Team2 min read06 steps

layer stack

Server

HWHardware
KKernel
RTRuntime
APPApplication
SYSSystem
CLIClient
NETNetwork
TLSCrypto
SRVServer

adjacent altitudes in this subsystem are still being traced

trace spine

  1. 01 DNS resolves to the load balancer IP
  2. 02 The load balancer selects a healthy backend
  3. 03 The backend builds a cache key and checks Redis
  4. 04 On a cache hit, the backend returns immediately
  5. 05 On a cache miss, the backend queries the database
  6. 06 The backend writes the result to cache and responds
▸ On this page

Consider a user request to GET /products/42 hitting a service deployed across three instances behind a load balancer. The request carries no useful cache context — the cache must derive its key from the product ID alone, not from any user-specific data.

1. DNS resolves to the load balancer

The browser's recursive resolver returns the load balancer's address. DNS TTL determines how quickly a failed or relocated balancer is discovered — too short and the resolver is overwhelmed, too long and failover is delayed.

2. The load balancer selects a healthy backend

The balancer consults its health-check state: which backends are passing active checks (HTTP 200 on /health) and passive checks (low 5xx rate on real traffic). A backend that is accepting connections but returning errors stays in the pool only if the check path exercises the real dependency stack.

3. The backend builds a cache key

The backend derives a key from the resource identity. If the response were authorization-dependent, the key would need to include the caller's identity or permissions — otherwise one user receives another's cached data. For a public product page, the key is the product ID alone.

4. Cache check

The backend queries Redis. A hit returns the stored product data in under a millisecond and skips straight to the response. The request cost is the network round-trip to Redis plus the TLS overhead already paid.

5. Cache miss → database

No entry exists. The backend falls back to the database. A single instance can now handle fewer concurrent misses — this is why cache hit rate is the most important metric on the critical path.

6. Write back and respond

The backend writes the result into Redis with a TTL (say, 5 minutes), then returns the response. Concurrent misses on the same key require single-flight coordination or the "thundering herd" will multiply the database load.

The cache is a consistency decision as well as a performance one. Read the database article to understand how the data being cached was durably written in the first place, and see the rate limiter practice for another traffic-control mechanism that lives on the same critical path.

Not started

Sign in to save your learning progress.

Sign in to save