Redis Caching Strategies

What this diagram shows

This diagram illustrates the three main Redis caching patterns and their interaction with application code and data stores. Cache-aside (lazy loading) shows requests checking Redis first, then falling back to the database and populating the cache on miss. Write-through demonstrates synchronous writes to both cache and database together. The diagram also captures cache stampede protection using locks or probabilistic early expiration, and invalidation strategies including TTL expiry, event-driven deletion, and manual cache clearing. It maps decision points where each pattern applies and the flow of data between application, Redis, and primary storage.

Key components

• Application Layer — Initiates read and write requests, chooses which caching pattern to apply based on access patterns and consistency requirements.
• Redis Cache — Stores frequently accessed data in memory with optional expiration, serving as the fast intermediate layer between application and database.
• Primary Data Store — Persists authoritative data (PostgreSQL, MySQL, DynamoDB, etc.) that must remain consistent with cached copies.
• Cache-Aside Handler — Checks Redis on read; on miss, queries the database and writes result back to cache for future hits.
• Write-Through Handler — Writes data to Redis and the primary store in a single transaction, ensuring cache and database are always consistent.
• Stampede Protection (Locks/Probabilistic Expiry) — Prevents multiple requests from simultaneously querying the database when a popular cache key expires by serialising lookups or refreshing early.
• Invalidation Strategy — Removes or refreshes stale data via TTL expiry, event-driven deletion, or explicit cache clear commands when source data changes.

When to use it

Use this diagram when designing caching layers for systems where consistency, performance, and operational complexity matter equally. It is essential for documenting decisions on read-heavy workloads (cache-aside), systems requiring strong consistency (write-through), or high-concurrency scenarios prone to cache stampedes. Choose it when you need to communicate to engineers which pattern applies to which data type, or when auditing whether your current caching strategy matches your availability and consistency needs.

Common mistakes

• Applying cache-aside uniformly without protecting against stampedes, causing thundering herd queries when a hot key expires under heavy load.
• Using write-through for all data and ignoring write latency penalties, especially when database writes are slow and real-time consistency is not required.
• Implementing TTL expiry as the only invalidation method without event-driven cache clearing, resulting in stale data served until the timer runs down after schema or business logic changes.

Adapting it to your system

Replace the generic 'Primary Data Store' label with your actual storage system (e.g. PostgreSQL, DynamoDB, Elasticsearch). Annotate the Redis component with your chosen client library (e.g. ioredis, Jedis, redis-py) and serialization format (JSON, MessagePack, Protocol Buffers). For cache-aside, specify your fallback query (e.g. SQL SELECT) and cache key naming scheme. For write-through, document whether you use transactions or dual writes, and your rollback strategy on partial failures. Add your stampede protection method (distributed locks via Redis SET NX, or formula for probabilistic early expiration). List specific invalidation triggers: database triggers, message queues (Kafka, RabbitMQ), or REST webhooks that signal cache clears.