Caching easy
Setting a short TTL (e.g., 60 seconds) on a cached object helps to:
- A Ensure that the object is eventually synchronized and written back to the primary database store.
- B Strictly limit the maximum amount of physical RAM that any single cached object can consume.
- C Minimize the risk of the data becoming significantly stale compared to the original source of truth.
- D Increase the overall cache hit ratio by ensuring that only the most popular items remain in memory.
Answer: C. Minimize the risk of the data becoming significantly stale compared to the original source of truth.
**TTL (Time-To-Live)** defines the lifespan of a cache entry. By expiring items after a set duration (e.g., 60 seconds), it enforces an upper bound on data staleness, ensuring that the application eventually fetches fresh data from the source of truth, even if the data doesn't change frequently.
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?
- 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?