Caching hard
A user writes to the DB Primary. 10ms later, they read from a DB Replica (which has 100ms lag), get stale data, and write it to the cache with a 1-hour TTL. What is the severity of this issue?
- A The issue is negligible because the database's inherent eventual consistency model will naturally resolve the discrepancy within 100 milliseconds.
- B The replication lag is 'pinned' in the cache; every subsequent read will serve stale data for the full 1-hour TTL duration of the cache entry.
- C This is a minor performance concern as the cache will eventually refresh its state as soon as the replica catches up to the primary node's log.
- D There is no functional risk because modern Redis clusters automatically detect and compensate for database replication lag during read operations.
Answer: B. The replication lag is 'pinned' in the cache; every subsequent read will serve stale data for the full 1-hour TTL duration of the cache entry.
This is **Replication Lag Amplification**. The cache fills the gap between the DB's eventual consistency and the application's need for speed. If a cache miss occurs during the lag window (100ms), and the cache writes the stale value with a long TTL (1 hour), the ephemeral lag becomes a persistent error for the duration of the TTL. Users will see old data for an hour, not just 100ms.
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?