AEM Security, Permissions & User Management

A load balancer distributes incoming client requests across multiple backend servers to maximize throughput, minimize response time, and avoid overloading any single server. Choosing the right load balancing strategy is crucial for building scalable systems.

Load Balancing Algorithms

1. Round-Robin

Requests are distributed sequentially across servers.

• Pros: Simple, fair distribution, no state management.
• Cons: Doesn't account for server capacity or current load. Fails if servers have different specs.

2. Least Connections

Directs traffic to the server with the fewest active connections.

• Pros: Better than round-robin for long-lived connections.
• Cons: Requires tracking connection state. Not ideal for short-lived connections.

3. Weighted Round-Robin

Assign weights to servers based on capacity. Higher-capacity servers get more traffic.

• Pros: Accounts for heterogeneous server capacity.
• Cons: Requires manual configuration and maintenance.

4. Consistent Hashing

Hash the client IP or request property to determine the backend server.

Hash(Client IP) % Number of Servers = Assigned Server

• Pros: Requests from the same client always route to the same server (useful for session affinity).
• Cons: Uneven distribution if servers have different weights. Requires virtual nodes for dynamic scaling.

Health Checks & Failover

A critical responsibility of a load balancer is detecting failed servers and removing them from the pool.

Active Health Checks

The load balancer periodically sends requests (HTTP GET, TCP ping) to each backend server.

• Interval: Check every 1-10 seconds (tunable).
• Timeout: If no response within 2-5 seconds, mark server as unhealthy.
• Grace Period: Remove server from pool only after consecutive failures (e.g., 3 failures).

Passive Health Checks

The load balancer monitors failed requests and marks servers as unhealthy on-the-fly.

• Pros: Immediate detection of failures.
• Cons: Can cause request failures during failover.

Failover Strategy

• Cold Failover: Clients are rerouted to healthy servers immediately (transparent).
• Warm Failover: Drain existing connections before removal (graceful).
• Hot Failover: Use heartbeats/consensus to detect failures before they affect clients.

Consistent Hashing with Virtual Nodes

In a system with dynamic scaling (servers added/removed), simple modulo hashing fails. Consistent hashing mitigates this by:

1. Mapping servers onto a virtual Hash Ring (0 to $2^ - 1$).
2. For each request, hash the client ID and find the next server clockwise on the ring.
3. If that server fails, requests naturally route to the next healthy server.

Virtual Nodes: Each physical server is represented by multiple virtual nodes on the ring. This improves load distribution and minimizes redistribution when servers join/leave.

Layer 4 vs. Layer 7 Load Balancing

Layer 4 (Transport Layer)

Load balancers make decisions based on IP address and TCP/UDP ports.

• Speed: Very fast (no need to parse application data).
• Limitation: Cannot route based on request path, headers, or method.
• Use Case: DNS, raw TCP/UDP streams.

Layer 7 (Application Layer)

Load balancers parse HTTP headers, URLs, and request bodies.

• Flexibility: Route /api/* to API servers, /images/* to CDN, etc.
• Overhead: Slower due to full request parsing.
• Use Case: Web applications, microservices.

Session Persistence (Sticky Sessions)

If your application stores session state in-process (not recommended), you need sticky sessions to ensure clients always hit the same backend.

• Cookie-based: Load balancer injects a cookie identifying the backend. Future requests from the client route to the same server.
• IP-based: All requests from the same IP route to the same backend.
• Cons: Breaks failover, causes hot spots, violates horizontal scalability.

Better Approach: Store sessions in a distributed cache (Redis) and allow stateless backends.