What if your favorite website forgot who you were every time you clicked a link?
Why Sticky sessions in HLD? - Purpose & Use Cases
Imagine a busy restaurant where customers are randomly sent to different waiters every time they order. Each waiter has to start from scratch, asking the same questions again and again.
This random assignment causes confusion and delays. Customers get frustrated repeating their orders, and waiters waste time understanding preferences. The service becomes slow and error-prone.
Sticky sessions solve this by always sending a customer to the same waiter. The waiter remembers previous orders, making service faster and smoother without repeating questions.
Load balancer sends requests randomly to any server.
Load balancer routes requests from the same user to the same server (sticky session).Sticky sessions enable consistent user experience by keeping user data tied to one server during their visit.
Online shopping sites use sticky sessions to keep your shopping cart intact as you browse different pages without losing items.
Random request routing causes repeated work and confusion.
Sticky sessions keep user requests tied to one server.
This improves speed, consistency, and user satisfaction.
Practice
sticky sessions in system design?Solution
Step 1: Understand sticky sessions concept
Sticky sessions ensure that a user's requests go to the same server to maintain session state.Step 2: Compare with other options
Options B and C describe load balancing and shared storage, not sticky sessions. To encrypt user data during transmission is about security, unrelated here.Final Answer:
To keep a user connected to the same server during their session -> Option AQuick Check:
Sticky sessions = same server connection [OK]
- Confusing sticky sessions with load balancing
- Thinking session data is always shared
- Assuming sticky sessions encrypt data
Solution
Step 1: Identify sticky session implementation methods
IP hashing is a common way to ensure requests from the same user go to the same server.Step 2: Eliminate unrelated options
Encrypting data and caching in CDN do not control session routing. Random assignment breaks stickiness.Final Answer:
Using IP hashing to route requests -> Option DQuick Check:
Sticky sessions use IP hashing [OK]
- Confusing encryption with session routing
- Thinking CDN caching manages sessions
- Assuming random server assignment keeps sessions sticky
Solution
Step 1: Understand cookie-based sticky sessions
The load balancer sets a cookie to identify the server handling the user's session.Step 2: Follow the cookie routing logic
Subsequent requests with the cookie go to the same server, Server A in this case.Final Answer:
Server A -> Option BQuick Check:
Cookie sticky sessions route to same server [OK]
- Assuming requests go to different servers
- Thinking load balancer handles requests directly
- Confusing random routing with sticky sessions
Solution
Step 1: Analyze IP hashing limitations
IP hashing depends on stable IP addresses to route requests consistently.Step 2: Identify cause of inconsistency
Dynamic IPs cause requests to appear from different IPs, breaking stickiness.Final Answer:
Users have dynamic IP addresses changing frequently -> Option AQuick Check:
Dynamic IPs break IP hashing sticky sessions [OK]
- Blaming shared database for session routing
- Confusing SSL with session stickiness
- Assuming cookies affect IP hashing
Solution
Step 1: Understand session storage setup
Sessions stored locally require users to connect to the same server to access their data.Step 2: Evaluate approaches for consistent routing
Cookie-based sticky sessions reliably bind users to servers, ensuring session continuity.Step 3: Compare other options
Shared DB removes need for stickiness but contradicts local storage. IP hashing can fail with IP changes. Client-side storage shifts session responsibility.Final Answer:
Use sticky sessions with cookie-based routing to bind users to servers -> Option CQuick Check:
Local sessions need sticky cookie routing [OK]
- Choosing shared DB when sessions are local
- Relying on IP hashing despite IP changes
- Ignoring server session storage needs
Ready to prove it?
Pass the test and this pattern moves unknown
