← Engineering decisions

Why a local cache in front of Redis, instead of Redis alone?

Because the two layers answer different questions — one removes the network, the other removes the cold start.


Redis alone removes database load. It does not remove the per-lookup network hop, and it makes Redis availability a hard dependency of the request path.

A small, short-TTL in-process cache in front of it removes the hop for the hottest keys and lets the service keep serving — degraded, on slightly stale data — when Redis is unreachable. Redis stays because it is what stops a freshly-scaled instance from stampeding the database to warm itself.

The cost is invalidation across N processes. That cost is real, and it is the reason to only do this for data that is read constantly and written rarely. For anything write-heavy, one level is the right answer.

Related work and writing

Case studyPayment Hub — Two-Level CacheLocal JCS → Redis → databaseDecisionWhy Kafka for cache invalidation rather than Redis pub/sub?Ordering per key, replay for instances that were down, and an audit trail of what invalidated when.JournalDesigning a Two-Level Cache with JCS and RedisA local in-process cache in front of Redis buys latency and resilience. It bills you in invalidation. Here is the accounting.
Next decisionWhy Kafka for cache invalidation rather than Redis pub/sub?