Redis Caching: The Cache-Aside Pattern

When to reach for a cache

If the same data is read far more often than it changes - a product page, a user profile, a config blob - and the query is expensive, a cache turns a 300ms database round-trip into a sub-millisecond Redis lookup. The standard pattern is cache-aside (a.k.a. lazy loading).

How cache-aside works

1. Read: look in Redis first. Hit -> return it. Miss -> query the database, store the result in Redis with a TTL, return it.
2. Write: update the database, then delete (invalidate) the cache key so the next read repopulates it.

Implementation (Python + Redis)

import json, redis
r = redis.Redis(host="localhost", port=6379, decode_responses=True)
CACHE_TTL = 30  # seconds

def get_product(product_id: int) -> dict:
    key = f"product:{product_id}"
    cached = r.get(key)
    if cached:                         # cache hit
        return json.loads(cached)
    product = query_product_from_db(product_id)   # cache miss -> DB
    r.setex(key, CACHE_TTL, json.dumps(product))  # store with TTL
    return product

def update_product(product_id: int, data: dict):
    save_product_to_db(product_id, data)
    r.delete(f"product:{product_id}")  # invalidate so next read is fresh

The decisions that actually matter

• TTL is your safety net: even if an invalidation is missed, stale data self-heals when the key expires. Pick a TTL you can tolerate being stale for.
• Invalidate on write, don't try to update the cache in place - deleting the key is simpler and avoids races.
• Cache the miss too (a short TTL on "not found") if a missing key is hammered, to avoid a stampede on the database.
• Key naming: entity:id (e.g. product:42) keeps keys predictable and easy to bust.

Cache-aside vs other patterns

• Read-through / write-through: the cache library talks to the DB for you - less code, less control.
• Write-behind: writes go to cache first, flushed to the DB async - fast, but risks data loss. Cache-aside is the safe default for most apps.