Session clustering in Spring Boot is configured by delegating HttpSession storage to a shared, distributed cache via Spring Session, so every application instance reads and writes the same session data.
Key Points: • Add the spring-boot-starter-data-redis and spring-session-data-redis dependencies to enable Redis-backed sessions. • Setting spring.session.store-type=redis switches Spring's session handling from the default in-memory implementation to Redis, with no controller code changes required. • Redis connection details (host, port, credentials) are configured through standard Spring Data Redis properties. • Because sessions live centrally, sticky sessions on the load balancer are no longer required, and any instance can safely handle any request. • This setup also means a server restart, deployment, or autoscaling event no longer wipes out active user sessions.
Example: A retail application behind a load balancer configures spring.session.store-type=redis pointing to a shared Redis cluster; a user's cart now survives even if their next request lands on a completely different server instance.
Code Example:
# application.properties
spring.session.store-type=redis
spring.redis.host=redis-cluster.internal
spring.redis.port=6379<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-data-redis</artifactId>
</dependency>Interview Tip: A concise interview answer is:
"I'd add Spring Session with a Redis dependency and set spring.session.store-type=redis, which routes all session reads and writes through a shared Redis store instead of each instance's local memory. That removes the need for sticky sessions and lets any instance serve any request."