How to Solve Session Sharing and Cache Issues in Distributed Systems

When designing a system, anticipating problems and solving them at the design stage greatly simplifies later development.

1. Session Sharing Issues

In a single‑node system a Session object can be stored in memory, but in a distributed or clustered environment the Session must be shared across nodes. Common solutions include:

Session Replication

After the first client request, the server creates a Session and synchronizes it to all other nodes, as shown in Figure 1.

Session Sticky

Load balancers such as Nginx tag each user (e.g., via a cookie) so that subsequent requests from the same user are always routed to the same server, as illustrated in Figure 2.

Dedicated Session Server

All Session objects are stored in an independent Session service; application servers retrieve Sessions from this service. This approach is recommended for large‑scale distributed systems and can use databases or distributed storage for persistence, as shown in Figure 3.

2. Cache Penetration and Avalanche

Cache can alleviate high‑concurrency pressure, but issues such as cache penetration and cache avalanche may arise.

Cache Penetration

When many queries request data that does not exist in the database, the cache cannot help and the database is overloaded (Figure 4). Solutions include:

Filter illegal queries (e.g., captcha, IP limits).

Cache empty objects to avoid repeated DB hits (Figure 5).

Maintain a hash repository of all valid keys; queries first check the repository before hitting the DB (Figure 6).

Cache Avalanche

If Redis suddenly fails, all cached data become unavailable and the database may be overwhelmed. Mitigation strategies:

Deploy a Redis cluster for high availability.

Stagger cache expiration times, adding random offsets.

Control concurrent DB access with queues or locks.