Cache Consistency Models

Cache consistency models describe how closely cached values track updates in the authoritative data store. In backend systems, the choice of model determines how much stale data clients may observe and what coordination or invalidation mechanisms are required.

A cache sits between an application and its authoritative data store, so an update can temporarily leave different copies holding different values. Cache consistency describes the guarantees governing what readers can observe during that period. The appropriate guarantee depends on application requirements rather than on the cache being simply "correct" or "incorrect."

With strong consistency, a successful write is expected to become visible to subsequent reads according to a defined ordering, but achieving this across distributed caches can require coordination and increase latency. Weaker models permit stale reads in exchange for simpler operation, higher availability, or better performance. In practice, many distributed applications deliberately accept bounded or eventual staleness.

For Java backend systems, common approaches include cache-aside, write-through, and write-behind strategies. Cache-aside gives the application responsibility for loading and invalidating entries, while write-through updates the cache as part of the write path. These strategies affect consistency behavior but are not themselves consistency models; the resulting guarantees depend on invalidation timing, replication, failures, and concurrent access.

A useful design question is what stale-data window the business can tolerate. If an entry may remain stale for seconds, TTL-based expiration can be sufficient for some workloads. If stale authorization or inventory information is unacceptable, stronger invalidation or coordination may be necessary. Distributed caches such as Redis can also introduce replication lag, failover effects, and race conditions that must be considered separately from the application's basic caching strategy.

Key points

• Consistency describes what cached reads may observe after writes.
• Strong guarantees generally require more coordination than eventual consistency.
• Cache-aside, write-through, and write-behind are caching strategies, not consistency models.
• TTL expiration limits staleness by time but does not prevent stale reads before expiry.
• Invalidation races, replication lag, and concurrent writes are major sources of cache inconsistency.

Interview questions

What is the difference between strong and eventual cache consistency?

Strong consistency provides a tighter guarantee about when reads reflect completed writes, subject to the precise system definition. Eventual consistency allows readers to observe older values temporarily while distributed copies converge. Stronger guarantees commonly require additional coordination or synchronization. Eventual consistency can reduce coordination overhead and is often acceptable when temporary staleness has limited business impact.

What is cache consistency, and why does it matter?

Cache consistency describes the relationship between values stored in a cache and the authoritative data source. After an update, a cache may still contain the previous value. The consistency model determines what stale data readers can observe and for how long under the system's guarantees. It matters because stale data can affect correctness, user experience, and business operations.

How does cache-aside affect consistency?

With cache-aside, the application reads from the cache first and loads missing entries from the database. On a write, the application commonly updates the database and invalidates the cache entry. This can work well, but the operations are not automatically atomic, so failures or concurrent requests can leave a stale entry temporarily. Correct ordering and race handling are therefore important.

How would you design cache invalidation for a distributed Java service?

I would first define the maximum acceptable staleness and identify which data requires stronger guarantees. For cache-aside, writes would update the source of truth and invalidate affected keys, while the design would account for failures between those operations. For multiple application instances, invalidation may need a shared mechanism such as messaging or a distributed cache protocol. I would also monitor invalidation failures, cache hit rates, and stale-read symptoms and test concurrent updates explicitly.

Can TTL alone provide cache consistency?

TTL provides a bound on how long an entry is intended to remain in the cache, but it does not make reads immediately reflect writes. Until an entry expires, readers may receive its old value. A shorter TTL reduces the potential stale period but can increase database load and cache misses. Applications requiring prompt visibility generally combine expiration with explicit invalidation or another coordination mechanism.