Cache TTL vs. Active Invalidation

Setting a five-minute TTL (TTL = 5m) may seem like a simple solution for cache consistency, but it only dictates when an entry expires on its own. It does nothing to address the exact moment a write mutation renders the stored value stale and incorrect.

If a database record changes in PostgreSQL while the prior version lingers in Redis for another four minutes, the application remains fast and responsive—yet it serves a truth that no longer exists. The severity of that discrepancy depends entirely on the domain semantics of the data.

Staleness Tolerance Defines the Strategy

For a public blog listing, a few minutes of stale data is often harmless. In authentication, authorization permissions, user balances, rate-limiting quotas, or inventory reservations, that identical lag can trigger incorrect business decisions, financial discrepancies, and unauthorized actions.

Designing a caching strategy must begin with the domain's tolerance for staleness. Defining exactly how long an entity can remain out of sync without violating business invariants determines whether a passive TTL is sufficient, or whether updates demand active, event-driven invalidation.

Active Invalidation Patterns

When strong consistency matters, waiting for an expiration timer to elapse is insufficient. Better architectural patterns include evicting the cache key immediately upon write, utilizing versioned keys, publishing invalidation events via pub/sub or change-data-capture (CDC), or proactively rebuilding the cached projection from the authoritative source.

Expiration vs. Invalidation

Every coordinated invalidation pattern trades architectural simplicity for consistency guarantees. Crucially, they enforce an explicit distinction: expiration is a time-based disposal policy to manage memory footprint, whereas invalidation is an event-driven reaction to state mutations that render existing data obsolete.

TTL as a Safety Net, Not a Consistency Model

TTLs remain vital as a safety net to clean up abandoned keys, handle naturally transient sessions, or recover from dropped invalidation messages. Treating TTL as the sole consistency mechanism, however, simply exposes end users to an arbitrary window of data corruption.

Sound cache architecture does not start by picking arbitrary intervals like five minutes because they feel safe. It begins by classifying staleness tolerance per data model and pairing that requirement with mechanisms that keep cached representations strictly coherent with reality.