Caching easy
In a Write-Back (Write-Behind) cache, data is acknowledged as 'saved' once it hits the cache. Synchronization to the DB happens later. What is the risk?
- A The average read latency for popular items increases significantly as the system waits for database confirmation.
- B The primary database becomes immediately overloaded with high-frequency write operations during peak traffic bursts.
- C There is a risk of permanent data loss if the cache node fails before it can successfully flush the changes to the DB.
- D The cache memory fills up prematurely because items are not evicted until they have been successfully synchronized.
Answer: C. There is a risk of permanent data loss if the cache node fails before it can successfully flush the changes to the DB.
**Write-Back** (or Write-Behind) caching offers extremely low write latency because the application only waits for the cache acknowledgment. However, if the cache server crashes before it asynchronously flushes the data to the persistent database, that data is permanently lost. This is a classic durability vs. latency trade-off.
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?