Caching medium
Why is 'Sticky Sessions' (Load Balancer affinity) considered less scalable than a 'Shared Session Cache' (Redis)?
- A Sticky sessions require the deployment of specialized, high-cost hardware load balancers that often lack modern cloud auto-scaling support.
- B Sticky sessions couple a client to a specific server; if that instance fails or scales down, the active user session data is permanently lost.
- C Shared session caches are inherently slower and more operationally expensive to maintain than local in-memory storage on each individual web server.
- D The use of sticky session affinity prevents the load balancer from terminating HTTPS connections and inspecting the encrypted request headers.
Answer: B. Sticky sessions couple a client to a specific server; if that instance fails or scales down, the active user session data is permanently lost.
**Sticky Sessions** route a user to the same server to maintain state (like a shopping cart in local memory). This breaks horizontal scalability: if that server crashes or is scaled down, the user loses their state. A **Shared Cache** (like Redis) decouples state from the application servers, allowing any server to handle any request statelessly.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In the Cache-Aside pattern, what happens when the application requests data that is missing from the cache (a 'Cache Miss')?
- Why use a centralized Distributed Cache (like a Redis Cluster) over local in-memory caches on each web server?
- Setting a short TTL (e.g., 60 seconds) on a cached object helps to:
- What is the primary architectural goal of introducing a cache into a system?
- Most caching systems rely on the principle of 'Temporal Locality', which states:
- Your cache uses an LRU (Least Recently Used) eviction policy. When the cache is full, which item is removed?