Answer #1 · 01:24
Define the consistency requirements first, then choose an update strategy.
1. Establish how much staleness is acceptable
The cache and database are separate stores, so writes have a consistency window. Product descriptions may tolerate delay; inventory and payment state need stronger checks. Clarify the business requirement before choosing the read path.
2. Update the database, then invalidate the cache
Read the cache first and populate it from the database on a miss. After a successful database transaction, invalidate the cached value so the next reader reloads it. Invalidation reduces the risk of out-of-order concurrent writes overwriting the cache with an older value.
3. Plan for failed invalidations and concurrent fills
Use traceable retry tasks, backoff, limits and alerts. A TTL bounds the lifetime of old entries. Also consider a reader that fetches stale data before a write and fills the cache afterward; version checks or change-log-driven invalidation may be necessary.
4. State the guarantee and explain verification
These approaches generally aim for eventual consistency. A TTL alone does not provide strong consistency. Verify with concurrent read/write tests, failure injection, retry-backlog monitoring and measurements of the inconsistency window.
The next question continues with the current conversation context.