Redis Cache Invalidation: Architecting Event-Driven Sync
Master Redis cache invalidation in distributed systems. Learn how to use event-driven architecture to keep your caches in sync with your database reliably.
Last month, we spent three days chasing a race condition where our user service served stale profile data for roughly 400ms after an update. We were using a standard cache-aside pattern, but the lag between our primary database commit and the cache deletion wasn't as atomic as we’d assumed. If you're building a distributed system, you know that keeping your distributed cache coherent with your source of truth is the hardest part of the job.
The Problem with Naive Cache-Aside
In a basic setup, your application writes to the database and then sends a DEL command to Redis. It sounds simple, but it fails under load. If your application crashes between the database commit and the cache deletion, your cache stays stale indefinitely. Worse, if you have multiple service instances, you’re relying on every instance to be a "good citizen" and clear the cache correctly.
We first tried adding the invalidation logic directly into the service's update method. It broke because of network partitions; sometimes the database update succeeded, but the Redis connection timed out. That’s when we moved toward an event-driven approach.
Implementing Event-Driven Invalidation
Instead of the application service handling invalidation, we treat the database as the source of truth and the cache as a secondary projection. By using Change Data Capture via Transactional Outbox for Distributed Consistency, we ensure that an event is emitted only if the database transaction commits.
The architecture looks like this:
- The service writes to the database and inserts an event into an
outboxtable in the same transaction. - A CDC connector (like Debezium) reads the transaction log.
- The event is published to a broker (Kafka or Redis Streams).
- A dedicated "Cache Invalidator" worker consumes these events and purges the stale keys.
Using Redis Pub/Sub vs Streams: Building Reliable Notifications is critical here. While Pub/Sub is fast, it lacks durability. If your invalidator worker is down during a publish event, that message is lost forever. We use Redis Streams to ensure that invalidation events are acknowledged and processed at least once.
Why This Architecture Scales
When you decouple the invalidation, you stop blocking your main thread on cache operations. You also centralize the logic. If you need to change your caching strategy—say, moving from simple DEL to a "warm-up" pattern where you re-fetch the data immediately—you only update the invalidator worker, not every CRUD service in your cluster.
| Approach | Consistency | Complexity | Durability |
|---|---|---|---|
| Naive Cache-Aside | Eventual | Low | None |
| Dual Write (DB + Cache) | Weak | Medium | Low |
| Event-Driven Invalidation | Stronger | High | High |
Handling Race Conditions
Even with event-driven invalidation, you can run into a "cache stampede" or a race where a stale read happens after the invalidation event arrives but before the worker processes it. We mitigate this by using a versioning strategy. Each cache entry includes a version_id. If the incoming event's version is older than the current cache version, we ignore it.
If you’re using Laravel Eloquent Cache-Aside: Implementing Decorators for Consistency, you can wrap your models to handle these version checks automatically. It cleans up your controllers significantly.
Are we ever fully consistent?
Not really. We’re aiming for "eventual consistency" with a very tight bound. In our current production environment, we see cache synchronization occur within about 50ms of the database commit. It’s not synchronous, but for 99.9% of user interactions, it’s indistinguishable from a real-time update.
Next time, I’d probably look into using Redis Gears to handle the invalidation logic closer to the data store, though I’m still cautious about moving too much application logic into the database layer. Always keep your invalidation logic observable; if your workers fall behind, you need to know immediately, or you’ll be debugging "ghost" data for days.
FAQ
Q: Why not use Redis Keyspace Notifications? A: Keyspace notifications are fire-and-forget and can put significant load on your Redis server. They aren't designed for reliable, high-volume cache invalidation in distributed systems.
Q: Does this replace the need for TTLs? A: Never. Even with a perfect event-driven pipeline, messages can get stuck or consumers can fail. Always set a TTL on your cache keys as a safety net for "self-healing" stale data.
Q: Is the overhead of an outbox table too high? A: It adds one extra insert per transaction, but the trade-off in data integrity is worth it. For most high-traffic applications, the database overhead is negligible compared to the cost of inconsistent application state.