7 Traffic Routing Strategies, Session Persistence, & Failover Management
A Load Balancer distributes incoming client traffic across multiple backend servers to ensure no single server bears too much load, preventing bottlenecks and single points of failure (SPOF).
Load balancers utilize 7 core algorithms and strategies depending on server capacity, session requirements, and geographical proximity.
7 Load Balancing Strategies & Algorithms
Redirects incoming requests in sequential cyclical order: Server 1 ➔ Server 2 ➔ Server 3 ➔ Server 1.
💡 Best for: Environments where all servers have identical hardware specifications and request processing times are uniform.
Redirects traffic to the server currently handling the fewest active connections.
💡 Best for: Applications with long-lived persistent connections (e.g. WebSockets, streaming) where session lengths vary significantly.
Redirects traffic to the server that is most responsive and serving responses with the lowest latency.
💡 Best for: Providing the fastest response times when backend servers have different performance specs.
Hashes the client’s IP address to consistently map future requests from that IP to the exact same server.
💡 Best for: Session persistence (Sticky Sessions) when user state/session info is stored locally on a specific server and not synced across nodes.
Servers are assigned weights based on capacity. Higher-capacity servers receive a proportionally larger share of traffic.
💡 Best for: Heterogeneous server clusters where nodes have different CPU, RAM, or network bandwidth specifications.
Redirects traffic to the server located closest to the user’s Geographical IP location.
💡 Best for: Global applications requiring latency reduction and localized content delivery (Geo-DNS routing).
Standard hashing (Server = hash(key) % N) breaks down when servers scale up or down because almost 100% of keys get remapped. Consistent Hashing solves this by mapping both servers and keys onto a circular ring topology.
⭕ Consistent Hash Ring & Clockwise Routing
Both servers and user requests are mapped onto a 360° circular hash ring. Requests travel clockwise to hit the first available server node.
💡 How Consistent Hashing Works (Step-by-Step):
Ring Topology: Backend servers (S1, S2, S3) are hashed by IP/name and placed at fixed points along a 360° circular ring.
Clockwise Request Lookup: When a user request (Key 1) arrives, its hash location is calculated on the ring. The system moves clockwise around the ring to find the first server it hits (S2).
Minimal Remapping on Crash/Add: If S2 crashes, only requests mapped to S2 move to S3. Keys on S1 & S3 remain 100% untouched!
🩺 Health Checks & Failover Management
The load balancer constantly sends periodic Health Check ping requests (e.g., HTTP /healthz endpoints or TCP heartbeats) to all registered backend servers.