load-balancinglisted

# Load Balancing Spread incoming requests across a pool of identical backends so no single server is the bottleneck or the single point of failure. Get it wrong and the balancer becomes the SPOF it was meant to remove, routes traffic to dead servers, or *amplifies* an outage by hammering a backend that is already on its knees. ## When to reach for this Reach for a balancer when more than one backend serves the same role and traffic must be split across them; when a single entry point is a SPOF to eliminate; to add or remove servers without clients noticing (the enabler for the stateless tier and autoscaling); or to put one public address in front of a private fleet, with TLS termination, health-gating, and routing in one place. ## When NOT to One backend that comfortably handles peak load needs no balancer yet — adding one is a new component, a new failure mode, and a new thing to operate (YAGNI). If the real bottleneck is the database or a single hot shard, a balancer in front of the web tier solves nothing; diagnose the actual constraint first (→ `back-of-the-envelope`). Cross-region traffic steering is usually DNS/anycast at the edge, not an L4/L7 balancer (→ `content-delivery`). Per-client request limiting is a policy concern owned by `resilience-failure`, not the balancing algorithm. ## Clarify first - **Protocol & layer need** — raw TCP/UDP throughput (L4) or HTTP-aware routing by path/host/header/cookie (L7)? This picks the balancer type. - **State** — is the bac