Caching easy
Why use a centralized Distributed Cache (like a Redis Cluster) over local in-memory caches on each web server?
- A Distributed caches are physically faster to access over a network than local system memory access.
- B To ensure that all web servers share a coherent state, such as consistent user session data across the cluster.
- C Local in-memory caches are strictly limited to storing primitive data types and cannot serialize complex objects.
- D Distributed caches utilize specialized protocols that do not require any serialization of the data being stored.
Answer: B. To ensure that all web servers share a coherent state, such as consistent user session data across the cluster.
Local caches are fast but isolated. If User A logs in on Server 1, their session data exists only in Server 1's memory. If a load balancer routes their next request to Server 2, they will appear logged out. A **Distributed Cache** (like Redis) provides a shared, coherent state accessible by all stateless web servers.
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')?
- 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?
- Redis and Memcached store data in RAM. What is the primary implication of this for system design?