Caching Patterns

Cache-aside (also called "lazy loading") is the most common caching pattern: the application checks the cache first; on a miss, it fetches from the real data source and writes the result INTO the cache for next time.

def cache_aside_get(key, cache, db):
    if key in cache:
        return cache[key]
    if key in db:
        cache[key] = db[key]
        return db[key]
    return None

The cache and database can drift out of sync (the cache might hold a STALE value after the database changes) — cache-aside deals with this via a TTL (time-to-live, from the HTTP course's Caching module) or by explicitly invalidating the cache entry whenever the underlying data changes.

Cache hit rate — the fraction of requests served from the cache instead of the underlying data source — is the standard metric for whether a cache is actually earning its keep:

def cache_hit_rate(requests, cache_keys):
    hits = sum(1 for r in requests if r in cache_keys)
    return hits / len(requests)

requests = ["a", "b", "a", "c", "a"]
print(cache_hit_rate(requests, {"a", "b"}))   # 0.8 -- 4 of 5 requests were cached

A low hit rate usually means either the cache is too small (useful data keeps getting evicted before it's reused) or the access pattern is genuinely random (nothing gets requested twice, so caching can't help at all) — worth diagnosing which before assuming "just make the cache bigger" is the fix.