Sync Session: Rethinking Session Management in Microservices
Project: Sync Session on GitHub
Shared storage provides the source of truth. Local caches provide performance. Events synchronize session state across service instances.
Since I started working with microservices in 2016, I have continuously explored and refined different approaches to session management.
One question has remained particularly important to me:
How can every service independently verify a user's session without turning authentication into a bottleneck?
In a microservices architecture, services frequently communicate with one another. From a zero-trust perspective, a service should not blindly trust a userId simply because another service included it in a request.
Instead, each service should validate the session and enforce the appropriate authorization rules.
However, querying a shared database every time a service needs to validate a session can increase latency and database load, especially when requests pass through multiple services.
This creates a practical engineering challenge: how do we preserve session validity and revocation capabilities while reducing the cost of repeated remote access?
That question led me to develop Sync Session, an open-source session management library for Spring Boot.
The Design
The design combines four main components:
- RDBMS as shared storage: The persistent source of truth for session state.
- Local cache: Each service instance maintains a local copy of session data to reduce repeated database queries.
- Event service: Session changes trigger events that allow other service instances to invalidate their corresponding local cache entries.
- Session ID propagation: The session ID can be passed through a cookie or HTTP header, depending on the application's request flow.
The session itself is intentionally kept small. Rather than embedding a large amount of user data and permissions into the session, the application uses a protected session ID to retrieve the associated authenticated identity.
User information and authorization data remain under the responsibility of the relevant systems, where they can be updated independently.
This separation helps avoid relying on outdated user information stored in a session and supports centralized session revocation.
What Does This Approach Support?
The project aims to address several practical requirements:
- Distributed session management across multiple service instances.
- Sliding session expiration, allowing the expiration time to be extended according to the configured policy.
- Administrative session revocation, enabling an administrator to force a user to log out.
- Synchronization of session invalidation across service instances.
- Reduced database access through local caching.
The key idea is that services can validate sessions locally in the common case, while shared storage and event-driven invalidation help coordinate changes.
In my MySQL load tests, I measured the following results under a workload involving 100 threads and 1 million sessions:
| Operation | Measured throughput |
|---|
| Session creation | ~15,533 operations/sec |
| Local cache access | ~20.01 million operations/sec |
| Direct database queries | ~69,278 operations/sec |
All 1 million session creation operations completed successfully in this test, with no reported failures.
Under these particular test conditions, local cache access achieved approximately 289 times the throughput of direct database queries.
These numbers are reference measurements from my test environment, not universal performance guarantees. The results depend on hardware, database configuration, query patterns, cache implementation, concurrency, and the exact benchmark methodology.
The comparison also measures different access paths, so it should not be interpreted as an end-to-end authentication benchmark.
Consistency and Security Trade-offs
Local caching introduces an important limitation: event-driven invalidation is asynchronous.
When a session is revoked, another service instance may still have a cached copy until it processes the invalidation event. Event delivery failures or temporary network partitions can extend this window.
For security-sensitive systems, this behavior needs to be considered explicitly. Depending on the threat model, additional safeguards may be necessary, such as bounded cache lifetimes, reliable event delivery, recovery mechanisms, or synchronous validation for particularly sensitive operations.
Likewise, validating a session is not the same as authorizing every operation. Services must still enforce their own authorization requirements, and internal service communication must be authenticated appropriately.
The goal is not to claim that local caching removes every security or consistency challenge. It is to explore a practical balance between independent session validation, efficient reads, and distributed session invalidation.
A Design Principle Worth Discussing
The principle behind Sync Session can be summarized as:
Shared storage for correctness. Local cache for performance. Events for synchronization.
This is not the only valid architecture, and it may not be appropriate for every workload. I am sharing it because session management is a recurring challenge in distributed systems, and I believe the trade-offs deserve discussion beyond the implementation of any single library.
I'd especially like to hear from engineers who have built authentication infrastructure at scale:
- How do you handle session revocation across multiple service instances?
- Would you accept a short invalidation delay, or require immediate revocation for every request?
- How do you balance database load, cache consistency, and security requirements?
- What failure scenarios would you consider essential to address in this design?
I'm happy to discuss the implementation, benchmark methodology, and architectural trade-offs.
