NOTE
1.4 How to Implement Distributed Sessions
Why process-local sessions break under horizontal scaling and how replication, shared session stores, and centralized authentication address the problem.
This is a historical learning note and may contain outdated or incomplete understanding.
1. What Is a Distributed Session?
A session is server-side state associated with a client. That state may live in process memory, a database, Redis, or another shared store.
When an application runs multiple instances, a session stored only in one process creates a routing dependency: a request that reaches another instance may not find the user’s session.
2. Implementation Options
2.1 Session Affinity or Replication
A load balancer can keep one user on one instance, or application instances can replicate session data. These approaches reduce application changes but make failover, scaling, and session synchronization more complex.
2.2 Shared Session Store
Store session state in a shared system such as Redis. Application instances remain largely stateless: each request presents an opaque session identifier and any instance can load the corresponding session state.
The session ID must be unguessable, expire appropriately, and be protected in transit and at the client.
2.3 Centralized Authentication / SSO
A dedicated identity or SSO service authenticates users and issues a credential or token that applications can validate or exchange for session state. Authentication and application session storage are related but distinct concerns.
3. Trade-offs
Shared sessions improve horizontal scaling but introduce a remote dependency. Replication keeps access local but adds synchronization traffic. Token-based designs reduce shared session lookups but require careful revocation, expiry, and claim design.