Skip to main content

Session Management and Clustering Overview

The first problem you encounter in a load balancing environment is Session Inconsistency. When the server that created a user's login session is different from the one handling the next request, the user gets bounced back to the login page because that server has no record of their session. This chapter covers the root cause of session inconsistency and systematically examines three strategies to solve it.

What is a Session?​

HTTP is a stateless protocol. The server treats each request independently and has no memory of previous requests. When state must be maintained β€” such as for login, shopping carts, or user preferences β€” a Session is used.

[Client]                               [Server]
   β”‚                                      β”‚
   β”‚  1. POST /login (ID/PW)              β”‚
   β”‚ ────────────────────────────────────▢│
   β”‚                                      β”‚  Session created
   β”‚  2. Set-Cookie: JSESSIONID=ABC       β”‚  {userId: 1001, role: admin}
   β”‚ ◀────────────────────────────────────│
   β”‚                                      β”‚
   β”‚  3. GET /dashboard                   β”‚
   β”‚     Cookie: JSESSIONID=ABC           β”‚
   β”‚ ────────────────────────────────────▢│  Session lookup β†’ authenticated
   β”‚  4. 200 OK (dashboard response)      β”‚
   β”‚ ◀────────────────────────────────────│

Sessions are stored in server memory (or files/DB), while the client only holds a cookie containing the session ID.

The Session Inconsistency Problem in Load Balancing​

Session Inconsistency Problem

When multiple servers are in play, the server that stored the session may differ from the one handling the next request.

Request 1 β†’ App1 login β†’ Session ABC stored in App1 memory
Request 2 β†’ App2 handles β†’ No Session ABC β†’ not logged in!
Request 3 β†’ App3 handles β†’ No Session ABC β†’ not logged in!

This is the Session Inconsistency problem.

Situations That Cause Session Inconsistency​

SituationDescription
Round Robin load balancingRequests distributed to different servers
Server restart after deploymentIn-memory sessions are lost
Server failure β†’ failoverSessions on the failed server are lost
Adding servers (scale-out)Requests may reach new servers with no existing sessions

Three Solution Strategies​

There are three main approaches to solving session inconsistency.

Strategy 1: Sticky Session​

The same user's requests always go to the same server. The load balancer ties users to servers using cookies or IP hash.

User A β†’ always App1
User B β†’ always App2
User C β†’ always App3

Advantage: Apply immediately without any application code changes. Disadvantage: If App1 goes down, User A's session is lost. Load may not be evenly balanced.

Strategy 2: Session Clustering (In-memory Replication)​

Tomcat's built-in cluster feature synchronizes sessions across all servers in real time.

App1 session changes β†’ replicated to App2, App3
β†’ The same session is accessible from any server

Advantage: Sessions survive server failure. No Sticky Session needed. Disadvantage: Increased network traffic between servers. Replication overhead grows with more servers.

Strategy 3: External Session Store (Redis)​

All servers share Redis (an in-memory data store) as a common session store.

App1 β†’ saves/reads sessions from Redis
App2 β†’ saves/reads sessions from Redis (same data)
App3 β†’ saves/reads sessions from Redis (same data)

Advantage: Most scalable. Servers can be freely added or removed. Disadvantage: Requires additional Redis infrastructure. Risk of losing all sessions if Redis fails (mitigated with Redis Cluster).

Strategy Comparison​

FeatureSticky SessionSession ClusteringRedis Session
Implementation complexityLowMediumHigh
Session preservation on failure❌ Lostβœ… Preservedβœ… Preserved
Scale-out flexibilityLowMediumHigh
Application code changesNoneNoneCode changes needed
Operational complexityLowMediumHigh
Best server countSmall (2~3)Small (2~5)Large scale

Chapter Learning Order​

This chapter covers the following in order:

  1. Sticky Session β€” Nginx ip_hash/cookie, Apache jvmRoute
  2. Tomcat In-memory Clustering β€” DeltaManager, BackupManager
  3. Redis-based Session Sharing β€” Tomcat Redis Session Manager, Spring Session
  4. Session Serialization β€” Implementing Serializable and performance optimization

Each approach is covered with hands-on configuration and a comparison of trade-offs.