Caching Patterns: Write-Through and Write-Back

Cache-Aside handles the read path well. But what happens when data is written? If a user updates their profile, the database gets the new data — but the cache still holds the old version. The two write strategies below address this problem in different ways.

Write-Through

In Write-Through, the application writes data to the cache, and the cache synchronously writes that data to the backing database before acknowledging success. The write is not considered complete until both the cache and the database have been updated.

Application ──write──▶ Cache ──synchronous write──▶ Database
                         │
                    Acknowledge
                    success only
                    after DB write

Pros:
- The cache is always consistent with the database. There is no window where the cache holds stale data after a write.
- Reads after writes always return fresh data.

Cons:
- Every write incurs the combined latency of writing to both RAM and disk/network. For write-heavy workloads, this can be a bottleneck.
- Data written once and never read again still occupies cache space (you can mitigate this by combining Write-Through with a TTL).

Write-Back (Write-Behind)

In Write-Back, the application writes data to the cache, and the cache immediately acknowledges success to the application. The cache then asynchronously flushes the data to the backing database in the background — on a timer, when memory pressure is high, or when the dirty entry is evicted.

Application ──write──▶ Cache ──acknowledge immediately──▶ Application continues
                         │
                    (background, async)
                         │
                         ▼
                      Database

Pros:
- Extremely fast writes for the application — it only waits for an in-memory write.
- Excellent for write-heavy workloads where many updates happen to the same key in a short window (the cache can coalesce multiple writes into a single database write).

Cons:
- Risk of data loss. If the cache server crashes before it flushes its dirty data to the database, those writes are permanently lost. This makes Write-Back unsuitable for financial transactions, order records, or any data where loss is unacceptable.
- More complex to implement correctly, especially around crash recovery and ensuring the async flush is reliable.