Skip to main content
When you add a cache in front of your database, you get faster reads and reduced DB load — but you also introduce a consistency problem. The database is the canonical source of truth; the cache holds a copy. If those copies diverge, users can see stale data. For example, if Lionel Messi updates his bio in the database but the cache still serves the old bio, the system is correct at the DB level but wrong at the user-visible layer.
Define how much staleness your application can tolerate before choosing an invalidation strategy. Measure the acceptable staleness window and use it to guide whether you need TTLs, active invalidation, or a hybrid approach.
There are two common strategies to keep cache and database consistent:
  • TTL (time to live): let cached items expire automatically.
  • Active invalidation: explicitly remove or update cache entries on database writes.
Below we explain both, when to use them, and common mitigations for their pitfalls.

​
TTL (time to live)

TTL means writing items into the cache with an expiry time. Example: set a user bio in Redis with a 60-second TTL. When the TTL expires, Redis evicts the entry; the next request misses the cache, fetches the latest data from the database, and repopulates the cache. TTL is a lazy approach: it trades eventual consistency for simplicity and scalability. It’s a good fit when short periods of staleness are acceptable (e.g., follower counts, trending metrics). But if your application cannot tolerate even a second of stale data (e.g., privacy settings), TTL alone is insufficient.
The image illustrates a system design using a Time to Live (TTL) cache mechanism, showing data flow between an app, Redis cache, and a database, with old and new bio information.

​
Cache stampede (thundering herd)

A common TTL-related failure mode is the cache stampede: when a very popular cache key expires, many clients request it simultaneously, causing a surge of identical DB queries. This can overload your database.
The image is a diagram illustrating a cache stampede scenario in a system involving an app, Redis cache, and a database, depicting the flow of photo requests from a user.
Mitigations for stampedes and TTL issues:
  • Add jitter to TTLs so hot keys don’t all expire at the same instant.
  • Request coalescing / single-flight: ensure only one in-flight DB fetch repopulates the cache for a given key.
  • Per-key mutexes or locks to serialize refreshes.
  • Background refresh (prefetching) for known hot keys.
  • Serve a slightly stale value while refreshing asynchronously (stale-while-revalidate).
The image illustrates a data flow process using "TTL, Time to Live" with an app accessing data through Redis cache and a database, showing elements like follower count and bio update times.

​
Active invalidation

Active invalidation means the application updates or deletes the cached copy as part of the write flow. Typical pattern: write the new value to the DB, then delete or update the corresponding cache entry so future reads fetch fresh data. This approach minimizes the staleness window and is required when correctness is critical. However, active invalidation can be tricky because of races. For example, a read may occur between the DB write and the cache delete, potentially repopulating the cache with the old value. Common strategies to make active invalidation safer:
  • Double-delete: delete the cache before and after writing to the DB (or delete after DB write and repeat shortly after).
  • Write-through / write-behind: write the value to the cache as part of the DB update so the cache holds the new value immediately.
  • Versioned keys or optimistic concurrency: include a version or timestamp in cache keys/values so readers can detect stale entries.
  • Distributed locks or single-flight: serialize cache refreshes to avoid races.
If you invalidate the cache in the wrong order relative to the DB write, you risk serving stale entries. Design your write+invalidate ordering carefully and consider extra safeguards (double-delete, versioning, or locking) to guarantee correctness.
The image illustrates a process of active invalidation involving an app, Redis cache, and a database, where a bio update is propagated through the system.
Active invalidation increases implementation complexity because every write path must include cache maintenance. It’s the right choice when staleness is unacceptable (security/permissions/privacy).

​
Choosing the right approach

There’s no single answer — choose based on your correctness requirements, traffic patterns, and operational complexity:
  • Use short TTLs (with jitter) for high-throughput, eventually-consistent data (home feed, counts).
  • Use active invalidation for security- or privacy-sensitive fields (permissions, feature flags).
  • Use longer TTLs for rarely-changing data (user profile information) to reduce read latency and DB load.
  • Combine strategies: TTLs + jitter for general load reduction, request coalescing to avoid stampedes, and active invalidation for critical fields.
The image illustrates a choice between using a short TTL (Time to Live) for a trending feed, where a few seconds of staleness is acceptable, and ensuring privacy settings that can't be stale even for a second.

​
Industry defaults (good starting points)

These are tunable defaults — measure your latency, cache hit rate, and correctness requirements and iterate.
The image illustrates industry benchmarks for various app features like "Home Feed" and "Trending List" with their respective time-to-live (TTL) durations, alongside a phone interface showing privacy settings.
One final point: the worst bugs are not when the cache is empty. The worst bugs are when the cache confidently serves wrong data. There’s an old joke that there are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

Watch Video