Write-behind (write-back).

The pattern is three steps, and the database is reached on none of them. The application writes data to Valkey. Valkey acknowledges immediately — the client receives success. A background process periodically reads changed data from Valkey and writes it to the database. The store update happens “behind” the cache write, hence the name.

The application stores the new value and records that the key changed — a write buffer, built as a List with LPUSH or a dirty-set with SADD. The caller is acknowledged the moment both succeed. A separate background worker drains the buffer with RPOP on a timer, reads the current value for each changed key, and writes the batch to the database in one round trip. The source is reached far less often than the application writes, and never on the request’s critical path.

The figure above traces the split: the write path stores the value and returns; the flush path drains the buffer and reaches the database on the next tick. Nothing about the acknowledgement waits for the database.

The application writes to Valkey and nothing else. No database interaction occurs during these operations; the background sync process later reads these values and persists them.

The write path adds one move to mark the key changed — LPUSH writebuf <key> onto a List buffer, or SADD dirty <key> onto a dirty-set — and the flush path drains it (RPOP, or SMEMBERS) and reads the current value before writing the source. On EchoStore the deferral is real code: the writer’s verb intend_and_enqueue/4 records the intent locally, hands the apply to the job lane over EchoMQ, and returns — the bus carries the apply off the write path.

• Extremely low write latency. Operations complete as soon as Valkey acknowledges — and, on EchoStore, after one local SQLite append — because no database round trip is on the request path.
• High throughput. The database is protected from write storms. Many rapid updates collapse into a single database write during sync.
• Write coalescing. If a counter is incremented 1000 times per second, only the final value needs to be written to the database, not 1000 individual increments. The third dive walks this step.

This pattern trades durability for speed, and the cost is exact. Data loss risk: if the cache fails before synchronization, any writes since the last sync are lost — the cache becomes the system of record during the sync window. Eventual consistency: the database lags behind the cache, so a query straight to the database may return stale data.

EchoStore closes that window not with a cache-side append log but with the outbox: the intent is recorded in a SQLite WAL before the bus hears it, and replay/2 re-enqueues every intent not yet covered by the applied memory. The bus already deduplicates a re-enqueued job id, and newer-wins makes a re-applied version harmless. The plain-store dials still apply where the buffer is a raw List: persistence (AOF bounds loss to the last fsync; RDB to the last snapshot), shorter sync intervals, and replication. The choice between write-through and write-behind is a choice about where the acknowledgement happens.

Write-behind excels where a small, bounded loss is acceptable in exchange for write throughput: counters and metrics (page views, likes, impressions), high-velocity session updates where database latency would be prohibitive, analytics ingestion at high speed, and coherence obligations on EchoStore — a changed risk limit must reach every cache copy, the job lane carries it at-least-once, and the journal makes the obligation survive a bus restart.

Never use write-behind for data where loss is unacceptable: financial transactions, order processing, user credentials or authentication data, or anything with regulatory compliance requirements.

The background synchronization typically works in four steps, and must handle failure so nothing is silently dropped. Scan for keys that have changed — using a dirty flag, a buffer List, or a timestamp. Read current values from the cache — so the source receives the latest state, never an intermediate one. Write to the database — batched, one round trip for many keys. Mark keys as synchronized — clear them from the buffer or dirty-set.

If a database write fails, the key must remain marked for retry — the buffer is the only copy until the source confirms. On EchoStore the equivalent is compact/1: an intent is retired only when its name carries an applied version at least as new — coverage, not acknowledgment, so the hot path pays no per-intent completion write. A burst of writes to one key collapses to a single source write: the dirty-set holds the key once however often it changed.

The dives follow the arc the buffer → the window → the coalescing: how the asynchronous buffer absorbs a burst, the durability window the deferral opens and how to bound it, and how repeated writes to one key collapse into a single flush. Read them in order — the async buffer starts.

EchoStore.Journal is the write-behind path made durable: a per-group SQLite file standing beside the bus, holding the intents outbox (record → enqueue → mark) and the applied memory (the last version applied per name). The job lane is Coherence.enqueue/5 over EchoMQ’s queue ecc.coh.<table>; the cargo is the 29-byte coherence message id <> ":" <> version. The committed record prices the memory.