Skip to content

Revision · Core Building Blocks

Part 1 walked the path of a single request and named the seven blocks it passes through. Its throughline: there is no secret part — every large system is the same toolkit in different proportions, and the skill is knowing what each block buys and what it costs.

  • DNS & request routing — a name becomes an IP through the resolution chain, TTL is the dial between freshness and load, and anycast/GeoDNS steer each user to the nearest healthy edge. This is step one, before any of your code runs.
  • Load balancers — one virtual address spreads traffic across a fleet, splitting at L4 (fast, opaque) or L7 (smart, inspects requests); health checks route only to the living, and the LB itself must not become a single point of failure.
  • Caching — storing the answer so you never recompute it, the highest-leverage performance win, priced in staleness; hit ratio is the one metric, eviction is forced because a cache is finite, and the hierarchy runs from browser to database.
  • Content delivery networks — caching pushed to the physical edge, filled by push or pull, great for static content and fought over for dynamic; the sharp cost is invalidation at the edge.
  • Databases: a field guide — six families (relational, key-value, document, wide-column, graph, time-series), each built for a data shape, and choosing wrong here is the most expensive mistake on the list.
  • Message queues — decoupling producers from consumers so slow or spiky work goes async; the queue-vs-log distinction, at-least-once as the delivery reality, consumer groups to scale the read side, and backpressure when consumers fall behind.
  • Reverse proxies & API gateways — the front door that hides the fleet and centralizes TLS, auth, rate limiting, routing, and aggregation, charging a single-point-of-failure tax for that centralization.

The blocks are a vocabulary; real systems are sentences built from them — a CDN is caching plus DNS routing, a gateway is a reverse proxy with opinions, and a load balancer only works because the app servers behind it are stateless. Internalize the trade-off on each page rather than the definition, and you can defend not just what a block is but why you placed it there and what breaks when it fails. Next, Part 2 goes deep on the hardest block to change: data.