Caching easy
Which scenario best describes a Write-Through caching strategy?
- A The application writes to the cache, and the cache immediately writes to the DB before returning success.
- B The application writes to the cache and receives immediate confirmation; the database is updated later.
- C The application writes directly to the database and sends an invalidation signal to the cache cluster.
- D The application writes to a persistent message queue, which then handles both cache and database updates.
Answer: A. The application writes to the cache, and the cache immediately writes to the DB before returning success.
In a **Write-Through** cache, the application writes data to the cache, which then synchronously writes to the underlying database. The write operation is considered complete only when *both* the cache and database are updated. This ensures strong consistency between the cache and the database but adds latency to write operations.
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?