Redis doesn’t keep itself in step with your database; the application (or a supporting process) decides when to load, update and invalidate cached data. Choosing the right caching pattern is about how much staleness the data can tolerate and how much write-path complexity you will accept.
| Pattern | How it works | Freshness after a write | Good fit |
|---|---|---|---|
| Cache-aside (lazy loading) | Read cache; on a miss read the database, populate the cache with a TTL. On update, write the database then delete the key | A reader can briefly see a miss or stale data until the next read repopulates | Read-heavy data that tolerates short staleness, such as a product catalogue |
| Reference-data prefetching | Load small, stable data at start-up and refresh it when the source changes; often no TTL | Warm on every read once refreshed | Categories, lookup tables, configuration |
| Write-through | Update the database and the cache in the same operation; return only after both succeed | Readers see the new value immediately | Read-heavy paths that need read-after-write freshness, such as prices |
| Event-driven invalidation | Writers append change events (for example to a Redis stream); consumers update or delete cached entries | As fast as events are processed; survives consumer restarts | Derived values such as order status projections |
| Session and state offload | Transient state lives only in the cache | Not applicable | Carts, sessions, agent short-term memory |
Cache-aside in Python
The cache is an optimisation, never the source of truth. This sketch follows the Learn pattern: Figure 9.1 shows the read path and the order of operations on an update.
CACHE_TTL_SECONDS = 300
def get_product(product_id: int) -> dict | None:
key = f"product:{product_id}"
cached = r.get(key)
if cached is not None: # cache hit
return json.loads(cached)
product = load_product_from_db(product_id) # cache miss
if product is not None: # avoid caching null values
r.set(key, json.dumps(product), ex=CACHE_TTL_SECONDS)
return product
def update_product(product: dict) -> None:
save_product_to_db(product) # 1. update the source of truth
r.delete(f"product:{product['id']}") # 2. then invalidateInvalidation and consistency rules
- Order matters: update the data store first, then remove the cache entry. If you delete first, another reader can reload the old value from the database into the cache before your update commits.
- TTL as a backstop: even with explicit invalidation, set a TTL so a missed invalidation, a direct database update or a partial failure can’t leave stale data forever.
- Write-through needs failure handling: the database and Redis don’t share a transaction. If the commit succeeds but the cache update fails, retry or invalidate the key; the reference architecture uses an outbox table and idempotent repair processing, and versions (row versions or ETags) in cached values so older retries can’t overwrite newer entries.
- Cache stampedes: when a popular key expires, many requests can hit the database at once. Mitigate with TTL jitter, request coalescing, stale-while-revalidate or a short distributed lock.
- Key naming: namespace keys by entity and ID (
product:42,user:1001:profile) and add a version when the value schema can change. - Outages: treat Redis failures as cache misses, with timeouts and circuit breakers so the database isn’t overwhelmed.
- Cache-aside doesn’t guarantee consistency; an external process can change the database at any time, and the change isn’t visible until the item is reloaded.
Common trap: Invalidating the cache entry before writing to the database “to be safe” - that ordering opens a window where a concurrent reader caches the old value again; write the database first, then delete the key.
Common trap: Choosing cache-aside when users must see their own update immediately - cache-aside can serve a miss or stale value right after a write; use write-through for read-after-write freshness.