Load Balancing

Load Balancing: Distributing Traffic Across Servers

When a single server can't handle all traffic, you add more servers. A load balancer sits in front and distributes incoming requests across them.

Load Balancing Algorithms

Algorithm	How It Works	Best For
Round Robin	Requests go to servers in order: A, B, C, A, B, C...	Equal-capacity servers
Weighted Round Robin	Stronger servers get more requests	Mixed-capacity servers
Least Connections	Send to the server with fewest active connections	Varying request durations
IP Hash	Same client IP always goes to the same server	Session persistence
Random	Randomly pick a server	Simple, surprisingly effective

Health Checks

Load balancers periodically ping each server (e.g., GET /health). If a server fails to respond, it's removed from the pool until it recovers.

Sticky Sessions

Some apps store session data in server memory. If a user's second request goes to a different server, their session is lost. Sticky sessions (via cookies) ensure the same user always hits the same server.

Better alternative: Store sessions in a shared store (Redis) so any server can handle any request.

Why Frontend Devs Should Care

• WebSocket connections need sticky sessions or a shared pub/sub layer (Redis).
• File uploads to one server won't be visible on another without shared storage.
• Caching: Each server has its own in-memory cache. Use a shared cache (Redis/Memcached) instead.
• Debugging: An error on "server 3" won't reproduce if you hit "server 1". Use request IDs for tracing.