Caching Strategies Explained: From Browser to Database and Managing Stale Data

Write‑through, write‑behind (also called write‑back), and write‑around are the three canonical patterns for keeping a writeable cache consistent with its backing store. Understanding their consistency guarantees, latency impact, and failure modes helps engineers pick the right strategy for a given domain.

Pattern definitions

• Write‑through: every update is sent to the cache and synchronously persisted to the database. The cache and the source of truth are always aligned after the write completes.
• Write‑behind: the application writes only to the cache; a background worker batches and flushes changes to the database asynchronously. The cache may temporarily diverge from the database.
• Write‑around: writes bypass the cache and go straight to the database. The cache is refreshed on the next read (cache‑aside pattern).

Consistency guarantees

Performance trade‑offs

• Write‑through adds the latency of two writes (cache + DB) to every operation, which is acceptable when consistency outweighs speed.
• Write‑behind offers the lowest write latency because the request returns after the cache write only; however, it introduces asynchronous flush overhead and requires a reliable background processor.
• Write‑around avoids cache pollution for infrequently read data, keeping cache hit ratios high, but the first read after a change incurs a cache miss and a full database read.

Typical use cases

• Banking / financial transactions: strong consistency is mandatory; write‑through is preferred despite the added latency, and the implementation should comply with standards such as SOC 2 and ISO 27001 for data integrity.
• Analytics pipelines, logging, social‑media counters: high write volume and tolerance for brief inconsistency favor write‑behind, provided the system uses durable queues (e.g., Kafka) to survive cache failures.
• User‑profile updates or feature‑flag toggles: updates are rarely read immediately, making write‑around ideal to keep the cache focused on hot read paths while still satisfying NIST guidelines for auditability.

In practice, many production systems combine these patterns: critical entities use write‑through, bulk telemetry uses write‑behind, and mutable user settings use write‑around. Selecting the right mix requires aligning the consistency model with the business‑level tolerance for stale data and the operational overhead of maintaining asynchronous flush mechanisms.

Cache invalidation is the mechanism that forces a cached copy to be refreshed after the source data changes. Three common techniques are TTL‑based, event‑based, and version‑based invalidation; each trades freshness for simplicity, latency, or implementation effort.

TTL‑based invalidation

A time‑to‑live value is attached to the cache entry at write time. The entry is automatically evicted after the interval expires, guaranteeing an upper bound on staleness.

• Simple to configure – no application code needed beyond setting the TTL.
• Staleness window equals the TTL (e.g., a 24‑hour TTL can serve data that is a day old).
• Best for data that changes predictably or can tolerate delayed consistency, such as news headlines or product‑catalog snapshots.

Event‑based invalidation

When a write occurs, the application publishes an invalidation event that deletes or updates the corresponding cache key. This keeps the cache near‑real‑time but requires the write path to know every cache key that depends on the changed row.

function updateProduct(id, payload) {
    db.update('products', id, payload);          // write‑through
    redis.del(`product:${id}`);                  // immediate invalidation
}

Version‑based invalidation

Instead of deleting a key, the cache key incorporates a version identifier (e.g., product:42:v5). On each update the version is incremented; older keys naturally expire via TTL.

function getProduct(id) {
    const version = db.getVersion(id);                 // atomic read
    const key = `product:${id}:v${version}`;
    return redis.get(key) || loadAndCache(id, version);
}

The classic race condition

When two processes interact with the same datum, a stale write can overwrite a fresh value:

1. Process A reads value A from the database.
2. Process B writes value B and invalidates the cache.
3. Process A writes value A back to the cache after B’s invalidation, re‑introducing stale data.

Mitigation patterns

• Invalidation queue: Serialize invalidations through a durable queue (Redis PUB/SUB, Kafka). Consumers apply deletes in the order they were produced, ensuring the stale write cannot outrun the invalidation.
• Versioned keys: As shown above, the cache key changes with each update, eliminating the race because a write can only affect the version it read.
• Write‑through with atomic cache update: Combine the database write and cache set in a single transaction when the store supports it (e.g., using MySQL’s INSERT … ON DUPLICATE KEY UPDATE together with a Redis Lua script).

Choosing a technique depends on the required data freshness, write latency tolerance, and operational complexity. In practice, many enterprise systems blend TTL for low‑risk data, event‑based invalidation for critical entities, and versioned keys for high‑throughput paths where race conditions are most likely.

Production systems rarely rely on a single cache because each layer offers a different trade‑off between latency and data freshness. A typical stack consists of:

• Edge/HTTP cache (CDN, reverse proxy) – stores whole HTTP responses for seconds to minutes, reducing round‑trip time to the origin server.
• In‑process memory cache (e.g., Guava, Caffeine) – holds frequently accessed objects for microseconds, but its size is limited to the JVM heap.
• Distributed cache (Redis, Memcached) – provides millisecond‑scale access across multiple instances and survives process restarts.

Each layer answers the question “how long can the data be stale?”: the edge cache may tolerate a max‑age=300 header (five minutes), the in‑process cache often uses a short TTL (seconds), and the distributed cache may keep data for an hour or more, depending on change frequency.

Balancing speed and freshness

The TTL determines the maximum staleness. A short TTL (< 5 s) yields near‑real‑time data but forces most requests to miss the cache, eroding performance. A long TTL (< 1 h) maximizes hit ratio but can serve outdated values, as illustrated by the 24‑hour TTL misconfiguration that caused stale pricing for twelve hours.

Key practices to avoid stale data and stampedes

• Cache‑aside reads with explicit invalidation: on a write, either delete the key or publish an invalidation event (Redis pub/sub, Kafka) so all layers drop the stale entry.
• Versioned keys: embed a version number (e.g., user:42:v3) so a write increments the version and old entries expire naturally.
• Write‑through for strong consistency: updates go to both cache and database synchronously, suitable for inventory or banking.
• Write‑behind where latency matters: writes land in the cache first and are flushed asynchronously, accepting a brief inconsistency window.
• Lock‑based cache refill (thundering‑herd mitigation): use SETNX or a distributed mutex so only one request repopulates a missing key while others wait or serve slightly stale data.
• Stale‑while‑revalidate headers: allow the edge cache to serve expired content while a background fetch refreshes it, keeping user latency low.

By combining these layers and safeguards, engineers can achieve sub‑millisecond response times for hot data while ensuring that critical business information remains consistent and up‑to‑date across the entire system.