Caching hard
You need to invalidate a cache key after a DB write. If the DB commit succeeds but the Redis call fails, data is inconsistent. How does the Transactional Outbox pattern solve this?
- A The application is re-architected to perform every write to the Redis cluster first, followed by a secondary commit to the primary database instance.
- B The system utilizes a localized Two-Phase Commit protocol that ensures the Redis and Database writes are either both successful or both discarded.
- C It inserts a 'cache_invalidation_event' into a DB table within the same transaction as the write, allowing a background process to reliably retry.
- D The failure is ignored by the application logic, as it relies on the relatively short Time-To-Live (TTL) of the cache entry to eventually restore consistency.
Answer: C. It inserts a 'cache_invalidation_event' into a DB table within the same transaction as the write, allowing a background process to reliably retry.
The **Transactional Outbox Pattern** ensures consistency between the DB write and the cache invalidation. By writing the 'invalidation job' to an 'Outbox' table in the *same* database transaction as the business data, you guarantee that the job exists if and only if the data was committed. A separate process then reliably executes the job (retrying until success).
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?