Write-Through Cache diagram template
Writes go through the cache, either synchronously to the database or batched behind it.
About this design
Where cache-aside leaves the application to coordinate, write-through and write-behind make the cache the front door for writes. With write-through, every write updates the cache and the database before it is acknowledged, so reads are always fresh and the database is authoritative, at the cost of write latency. With write-behind, the cache acknowledges immediately and a background worker flushes batches to the database later, which absorbs bursts and reduces database load but risks losing the buffered writes if the cache node dies before they are flushed. This template shows both paths so a team can choose deliberately. Discuss durability guarantees, ordering of coalesced updates, replaying a queue after a crash, and which data, such as view counters or likes, is genuinely safe to lose a few seconds of.
Diagram as text
This is the source of the diagram, in the ArchBoard diagram DSL. Paste it into Tools, Diagram from text to rebuild or change it.
title "Write-through and write-behind"
direction LR
service app "Application"
app -[write-through]-> cache redis "Cache" -[sync write]-> db postgres "Database"
app -[write-behind]-> cache
cache -> queue sqs "Flush queue" -> worker flush "Batch writer" -> database
