Database caching: Implementing Redis Write-Through for Consistency

My team spent three days debugging a "ghost data" issue where users saw stale balances for about 280ms after a transaction, simply because our cache invalidation was firing asynchronously. We realized that if you're building high-concurrency systems, you can't just slap a cache in front of your database and hope for the best; you need a strategy that guarantees correctness.

Why Write-Through Caching Matters

Most developers start with "cache-aside." Your application checks Redis, misses, queries PostgreSQL, and then updates Redis. It’s easy to implement, but it leaves a window open for race conditions. If a concurrent write hits the DB while your application is busy updating the cache, you're toast.

Database caching using a write-through pattern flips the script. Instead of the application managing the cache, the write operation forces an update to both the persistent store (PostgreSQL) and the cache (Redis) within a single logical flow. When done correctly, this eliminates the "stale data" window entirely.

Designing the Write-Through Strategy

The core requirement of a redis write-through implementation is atomicity. If your database write succeeds but your Redis update fails, your system enters an inconsistent state.

Here is how we structured our service layer to handle this:

1. Start a database transaction.
2. Execute the UPDATE or INSERT query.
3. Update the corresponding key in Redis.
4. Commit the transaction.

If step 3 fails, we roll back the database transaction. This ensures that the cache and the database never diverge. While this adds a slight latency penalty to your writes—since you're waiting on the Redis SET command—it’s a trade-off that usually pays for itself in read-heavy environments.

PYTHON
def update_user_profile(user_id, data):
    # Start a transaction
    with db.transaction():
        user = User.objects.get(id=user_id)
        user.update(**data)
        
        # Write-through to Redis
        redis_client.set(f"user:{user_id}", json.dumps(data))

The "Gotchas" of Data Consistency

The biggest danger here isn't the code; it’s the network. What happens if the Redis instance is down? If your write-through logic is strictly coupled, your entire write pipeline crashes.

We learned this the hard way during an outage last year. Our application logic assumed Redis would always be there. When the Redis cluster hit its memory limit and stopped accepting writes, our database writes started failing too.

To solve this, we moved toward a more resilient pattern. We keep the write-through, but we wrap the Redis operation in a try-except block. If Redis fails, we log the error, invalidate the cache key (to force a clean fetch later), and allow the database transaction to commit. This is a form of "soft" data consistency—we prioritize system availability over perfect cache state, but we ensure the DB remains the source of truth.

Addressing Cache Invalidation

Even with a write-through strategy, you’ll eventually run into edge cases where the cache gets out of sync. Maybe a background job updates the database directly, bypassing your service layer.

This is where cache invalidation becomes a critical safety net. Never rely solely on write-through. Implement a TTL (Time-to-Live) on all cached objects. Even if your write-through logic fails silently, the cache will naturally expire, forcing the application to fetch fresh data from the source.

If you're interested in how this fits into a larger architecture, I’ve previously written about killing N+1 queries at the database layer: A practical guide to reduce the initial load on your primary store. When you're managing complex state, you might also find it useful to evaluate when to denormalize your database for production performance to simplify what actually gets cached.

FAQ: Common Implementation Questions

Q: Does write-through caching slow down my write operations significantly? A: Yes, it adds a network round-trip to Redis. For most applications, this is negligible (typically < 2ms). If your write throughput is extremely high, you might need to reconsider your architecture and look into asynchronous queue-based invalidation instead.

Q: How do I handle large datasets that don't fit in Redis? A: Don't cache everything. Use a "cache-aside" strategy for large, rarely accessed objects and reserve your write-through logic for high-frequency, small-payload objects like session data or user configuration.

Q: Should I use a Redis hash or a JSON string? A: It depends on your access patterns. If you frequently update individual fields, a Redis Hash is better because you can use HSET to update only the changed fields without fetching and re-serializing the entire object.

Final Thoughts

We’re currently experimenting with using Change Data Capture (CDC) tools like Debezium to automate this process. Instead of hardcoding the cache update in the service layer, we let the database transaction log drive the cache state. It’s cleaner, but it introduces more infrastructure complexity.

For now, the manual write-through approach keeps our database performance predictable and our code easy to reason about. Just remember: keep your transactions short, handle Redis failures gracefully, and always—always—have a TTL on your keys.