Caching easy
In the Cache-Aside pattern, what happens when the application requests data that is missing from the cache (a 'Cache Miss')?
- A The cache transparently fetches the data from the database and returns it directly to the application.
- B The application receives a null result and must fetch the data from the source itself, then update the cache.
- C The request is immediately terminated with a 404 error code until a background worker warms the cache.
- D The database triggers an asynchronous push operation to populate the cache with the missing resource key.
Answer: B. The application receives a null result and must fetch the data from the source itself, then update the cache.
In the **Cache-Aside** pattern (also called Lazy Loading), the cache is passive. The application is responsible for the lifecycle: it requests data from the cache; if it misses (returns null), the *application* must fetch the data from the database and then explicitly write it to the cache for future use.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- 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?
- Redis and Memcached store data in RAM. What is the primary implication of this for system design?