jonnify·persistence /echo-persistence/durability-spectrum/inherited-valkey-durability

Module 1 · Dive 1.1

Inherited Valkey durability.

EchoMQ enqueues on Valkey, so it inherits Valkey’s durability. With the append-only file flushed once a second, a write is safe within a second — on one box. The exposure is not abstract: it is exactly the writes accepted since the last flush. Move the crash and watch it.

§1

The one-second window

valkey persistence
AOF, appendfsync everysec. Writes arrive left to right; a dashed line is a flush to disk. Drag the crash — everything since the last flush is the lost window.
accepted writes time → crash
readout · Drag the crash. The lost window is the run of writes after the last flush — at most one flush interval of work, and on a single box, gone for good.

The shape is the lesson: durability here is a window, not a guarantee. Tightening the flush to every write closes the window but turns each write into its own flush — the strict, low-throughput corner of the spectrum. Loosening it widens the window for throughput. Same knob as everywhere else; Valkey simply ships it set to one second.

§2

When it is, and isn’t, enough

graft.design.md

For most work a one-second window is fine: a dropped metric or a retried side-effect costs nothing. For the jobs Echo Persistence exists for — a payment, the recorded product of a completed job — two things are missing, and the timeline shows both. First, the lost window is real work that was acknowledged and then vanished. Second, and invisible on a single timeline, nothing has left the machine: lose the box and you lose the file. Closing the window is one axis; getting the state off the box is the other — Dive 1.3 separates them, and the rest of the course reaches the corner where both are answered.

§3

References & sources