Sticky sessions in HLD - System Design Guide

Problem Statement

When a load balancer distributes user requests randomly across multiple servers, the user's session data may be lost or inconsistent because subsequent requests go to different servers without shared session state. This causes failures in applications that rely on session persistence, such as shopping carts or login states.

Solution

Sticky sessions solve this by making the load balancer route all requests from the same user to the same backend server. This is done by tracking a session identifier, often stored in a cookie or IP address, so the server handling the first request continues to handle all subsequent requests from that user, preserving session state locally.

Architecture

User Client ├──────▶

Load Balancer

→Load Balancer

↓

Server A

This diagram shows a load balancer routing user requests to backend servers. Sticky sessions ensure requests from the same user always go to the same server, preserving session state.

Trade-offs

✓ Pros

→

Preserves user session state without requiring shared session storage.

→

Simplifies application design by keeping session data local to one server.

→

Reduces latency by avoiding external session stores.

✗ Cons

→

Can cause uneven load distribution if some servers get more sticky sessions.

→

Limits fault tolerance; if a server goes down, users lose their session.

→

Scaling is harder because sessions are tied to specific servers.

Use sticky sessions when session state is stored locally and shared session storage is not available or too costly, especially for moderate traffic systems under 10,000 concurrent users.

Avoid sticky sessions in very large scale systems with thousands of servers or when high availability and fault tolerance require session data to be shared or replicated.

Real World Examples

Amazon

Uses sticky sessions in some legacy parts of their e-commerce platform to maintain shopping cart state without a centralized session store.

Netflix

Avoids sticky sessions by using stateless services and external session stores, but used sticky sessions early on to simplify session management.

Uber

Uses sticky sessions in their dispatch system to keep user requests routed to the same backend for consistent state during a ride.

Alternatives

Distributed session store

Stores session data in a centralized or distributed cache accessible by all servers, allowing any server to handle any request.

Use when: Choose when you need high availability and fault tolerance with many servers and cannot afford session loss.

Token-based stateless sessions

Encodes session state in tokens (like JWT) sent with each request, eliminating server-side session storage.

Use when: Choose when you want to scale horizontally without session affinity and can tolerate stateless session design.

Summary

Sticky sessions route all requests from a user to the same server to preserve session state.

They simplify session management but can cause uneven load and reduce fault tolerance.

Alternatives like distributed session stores or stateless tokens offer better scalability and availability.