Write-behind

Writes go to the cache and are flushed to the database later in batches. Writes are very fast, but anything not yet flushed is lost if the cache node fails, so it suits counters more than payments.

Where it shows up in real systems

  • In-memory cache

    The hit ratio depends on how much of the working set fits in memory, the TTL and the eviction policy. If the cache goes down or is flushed, every read falls on the database at once: plan for that stampede. Write-behind is fast but loses writes if a node dies without a replica.

    In production: Redis (Amazon ElastiCache, Azure Cache), Valkey, Memcached, Dragonfly

See it break, then fix it

Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.

Open the learning path Open the sandbox