Maintain cache-database consistency by synchronously writing to both Redis and the database before returning success—ensures reads always hit cache with fresh data.
Every write operation updates both the cache and the backing database synchronously before acknowledging success to the client. This eliminates cache misses for recently written data at the cost of higher write latency.
When a write occurs:
The cache and database are always updated together, maintaining consistency between them.
A typical write-through operation:
SET user:123 "{...updated user data...}"
Followed immediately by the corresponding database write. The application only returns success to the client after both operations complete.
Strong consistency: The cache always reflects the latest data. There is no window where the cache contains stale information (assuming both writes succeed atomically from the application's perspective).
Fast reads after writes: Data written is immediately available in the cache for subsequent reads. This benefits write-then-read patterns.
Simpler cache invalidation: Since writes go through the cache, there's no need to explicitly invalidate keys after database updates.
Increased write latency: The write operation isn't complete until both Redis and the database acknowledge. The total latency is at least the sum of both write latencies.
Cache pollution: Data that is written but rarely read still occupies cache memory. This can evict more valuable frequently-read data.
Failure complexity: If the database write fails after the cache write succeeds, you have an inconsistency. Applications must handle partial failures carefully.
The safest approach is to write to the database first:
This way, the database (source of truth) is always correct. A cache miss simply results in reading fresh data from the database.
This pattern works well when:
Consider other patterns when: