Choose the Pattern Before the Cluster
Cache-aside remains the default for enterprise workloads: the application reads from Redis, falls through to the database on a miss, and populates the cache. It is simple and it fails safely. Read-through and write-through move that logic into the caching layer, reducing application code but coupling availability of the cache to availability of writes. Write-behind offers the best write latency and the worst durability story; it belongs only where losing recent writes is genuinely acceptable.
Most performance problems attributed to Redis are actually pattern problems — a write-through cache in a system that needed cache-aside, or a cache placed in front of a query that was never the bottleneck.
Invalidation and Key Design
Stale data is a correctness bug wearing a performance costume. Time-to-live alone is a guess; event-driven invalidation triggered by the write path is deterministic. Versioned key namespaces allow an entire logical set to be invalidated by incrementing a version rather than scanning for keys — and scanning is what turns invalidation into an outage.
- Namespace keys by entity and schema version: user:v3:1042:profile.
- Never use KEYS in production; use SCAN or versioned namespaces.
- Add jitter to TTLs so large key sets do not expire simultaneously.
- Keep values small — large values create head-of-line blocking on a single-threaded core.
Failure Behavior Under Load
Three failure modes dominate. A cache stampede occurs when a hot key expires and every request rushes the database simultaneously; a per-key mutex or probabilistic early recomputation prevents it. A thundering herd on cold start happens after a cluster restart; staged warming and request coalescing contain it. Cache penetration — repeated lookups for keys that do not exist — is absorbed by caching negative results briefly or fronting lookups with a Bloom filter.
Critically, the application must remain functional when Redis is unavailable. Short timeouts, a circuit breaker, and a degraded-but-serving fallback are what separate a slow hour from a full outage.
Topology and Capacity
Redis Cluster shards by hash slot and scales horizontally, but multi-key operations must stay within a slot, which makes hash tags a design decision rather than an afterthought. Sentinel provides failover for a single primary and is sufficient for many enterprise workloads. Size memory against working set plus fragmentation overhead, choose an eviction policy deliberately — allkeys-lru for caches, noeviction for queues — and monitor hit ratio, evicted keys, and p99 command latency rather than average latency.