Caching Systems (Redis & Memcached)

Databases are excellent sources of truth, but many user requests ask the same question repeatedly: "What is product 123?", "Is this feature flag enabled?", or "What are the top posts?" Without caching, every repeated request consumes database CPU, locks, network round trips, and query planner work.

request -> app -> cache GET product:123
                 ├─ hit: return cached JSON in ~sub-ms
                 └─ miss: query database, compute response, SET cache with TTL

• Latency: memory lookups are usually far faster than disk or complex database queries.
• Capacity: repeated reads hit the cache, leaving database capacity for writes and uncached queries.
• Failure isolation: a warm cache can keep read-only parts of a site alive during partial database trouble.

Memcached is a small, fast, distributed string cache. Redis is a richer data-structure server that can also act as a cache, lightweight queue, counter store, rate limiter, pub/sub broker, and coordination primitive.

Redis is popular because operations run close to the data and are atomic on a single instance or shard. Instead of fetching a blob, changing it in app code, and writing it back, you ask Redis to perform a data-structure operation directly.

ZADD leaderboard 8700 user:42
ZADD leaderboard 9100 user:99
ZREVRANGE leaderboard 0 9 WITHSCORES

# Redis maintains score order, so top-N does not require scanning every player.

Atomic operations matter

INCR lets many clients update a counter without lost updates. Sorted sets keep rankings ordered while scores change. Lua scripts or transactions can combine a few operations when a rate limiter or seat hold must be checked and updated as one unit.

A pure cache can disappear and be rebuilt. Redis often holds state that is expensive or temporarily important, so teams enable persistence and high availability. Be clear whether Redis is disposable cache or semi-durable operational state.

The write strategy defines how the cache and source of truth stay aligned. Most bugs come from forgetting that an update must either invalidate or refresh every cached representation affected by the change.

def get_product(id):
    key = f"product:{id}"
    cached = redis.get(key)
    if cached:
        return decode(cached)

    product = db.query("SELECT * FROM products WHERE id = ?", id)
    redis.set(key, encode(product), ex=300)  # 5 minute TTL
    return product

def update_product(id, patch):
    db.update_product(id, patch)             # source of truth first
    redis.delete(f"product:{id}")            # force next read to refill

Cache memory is finite. When Redis or Memcached is full, it must evict something or reject writes. Good cache design treats eviction as normal, not exceptional: the database must still answer correctly when the cache is empty.

• TTL: each key expires after a configured time. Add jitter so thousands of keys do not expire at the same second.
• LRU / LFU: evict least-recently-used or least-frequently-used keys when memory is full.
• noeviction: reject new writes instead of evicting. Useful when keys are not safely disposable.

val = redis.get(key)
if val is not None:
    return val

# only one request should rebuild the hot key
if redis.set("lock:" + key, "1", nx=True, ex=10):
    val = recompute_from_db()
    redis.set(key, val, ex=300 + random_jitter())
    redis.delete("lock:" + key)
    return val

sleep_briefly()
return redis.get(key) or fallback_response()

Redis and Memcached are implementation tools. The system design ideas are covered more generally in caching basicsand in the Redis architecture pattern at Redis. Always decide which layer owns the cache: browser, CDN, application memory, distributed cache, or database buffer cache.