Spring Session + Redis for Distributed Session Storage
Fast recall
Quick revision
Core answer
Understanding of the stateless application pattern, sticky session problems, and how Redis-backed sessions enable horizontal scaling.
Using Spring Session without setting appropriate session timeouts, leading to Redis being filled with abandoned sessions that consume significant memory.
Mention the difference between cookie-based and header-based session ID propagation, discuss session data serialization concerns, and explain how Spring Session supports multiple session repositories (Redis, JDBC, Hazelcast).
Interview-ready guide
Interview answer
Spring Session replaces the default in-memory HttpSession with a Redis-backed session store, enabling horizontal scaling without sticky sessions.
The problem it solves
- By default, Spring Boot stores sessions in application memory — which means if a load balancer routes a user's second request to a different app instance, that instance has no record of the session, and the user appears logged out
- The traditional fix is sticky sessions (session affinity): the load balancer pins each user to one instance; the problem is that instance failures lose all sessions on that node, and load distribution becomes uneven as instances have different session loads
- Spring Session externalizes the session to Redis: every instance reads from and writes to the same Redis store, which means any instance can handle any request for any user
Configuration in Spring Boot
- Add
spring-boot-starter-data-redisandspring-session-data-redis; the session store is auto-configured; configure timeout withserver.servlet.session.timeout - Spring Session serializes the session to a Redis Hash under
spring:session:sessions:{sessionId}— each session attribute is a Hash field; reading one attribute doesn't deserialize the entire session
Session clustering considerations
- Redis for sessions introduces a network round trip on every request — typically fast (sub-millisecond on the same network), but it's worth measuring; use connection pooling to avoid connection overhead
@SessionScopebeans work correctly with Spring Session — the session bean's lifecycle is tied to the Redis-backed session, not the application instance- Configure session serialization carefully: the default Java serialization can cause ClassNotFoundException after a deployment if serialized classes change; use JSON serialization with a consistent schema
Spring Session + Redis for Distributed Session Storage
Direct Answer
Spring Session replaces the default in-memory HttpSession with a Redis-backed session store, enabling any application instance to serve any request regardless of which instance created the session. You add spring-session-data-redis to your dependencies, annotate a configuration class with @EnableRedisHttpSession, and configure a Redis connection — Spring's autoconfiguration handles the rest. Session data is stored as a Redis Hash, and the session ID is passed via a cookie or HTTP header.
Common Mistakes & Pitfalls
Using Spring Session without setting appropriate session timeouts, leading to Redis being filled with abandoned sessions that consume significant memory.
Check your understanding
Answer these without looking back at the article.
- How would you propagate the session ID in a REST API that does not use cookies?
- What serialization format would you choose for Spring Session data in Redis?
- How does Spring Session handle session expiry notification events?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.