Write-Through Cache
Write to the cache and the database together on every write, so the cache is always fresh — at a write-latency cost.
A write-through cache updates the cache and the underlying database together on every write, so the cache never holds stale data. It trades slightly slower writes (two stores per write) for always-consistent reads.
Worked example: on a profile update the app writes to Redis and Postgres in the same operation, so any subsequent read hits a warm, correct cache. Gotcha: it keeps the cache fresh but wastes effort caching data that may never be read, and it does not by itself solve durability — a common variant is write-behind (write to cache now, flush to the database asynchronously), which is faster but risks losing writes on a crash.