Persistence: RDB vs AOF.

RDB takes a point-in-time snapshot: the server forks, the child writes the whole dataset to one compact file, and the parent keeps serving. The file is small and restarts from it are fast, which makes RDB a good fit for disaster-recovery backups, fast instance bootstrapping, and development environments. The cost is the window: a snapshot taken every K seconds means a crash loses up to K seconds of writes — the whole interval since the last snapshot, not a bounded slice of it.

RDB alone is a backup mechanism, not a durability guarantee. The snapshot is the dataset as of the last fork; the writes after it live only in memory until the next one. For a record of truth that is not enough, which is why a primary store reaches for the log.

AOF writes a log of every operation that changes the dataset. On restart the server replays the log and the dataset is rebuilt. The loss bound is set by appendfsync — how often the log is flushed to the disk. Three policies trade durability against latency:

always fsyncs on every write — no loss, but the disk is on the critical path of every command. no hands the decision to the operating system — fast, but the loss bound is whatever the kernel's flush interval happens to be. everysec flushes once a second on a background thread: the worst case is about one second of writes, paid off the command path. For a primary store, everysec is the standard choice.

Hybrid persistence sets aof-use-rdb-preamble yes: the AOF file starts with a compact RDB-format snapshot, then the incremental commands since. The rewrite is small and the restart is fast, while the log still bounds loss to the appendfsync window. It is not RDB snapshotting on a timer — it is the AOF rewrite borrowing the RDB encoding.

The textbook says enable both. EchoMQ's real infra/valkey/conf/valkey.conf does the opposite, and on purpose. The persistence block is the as-built tuning surface — save "" turns RDB snapshotting off, and the append-only log is the single source of durability.

appendonly yes + appendfsync everysec make the append-only log the single source of durability, with the ~1s bound paid on a background thread. aof-use-rdb-preamble yes keeps the compact RDB format for the AOF rewrite, so a restart is still fast. save "" disables RDB snapshotting. The reason both are not on is the fork: command execution is single-threaded, and a fork's copy-on-write spike must be budgeted under the machine's RAM. Two independent fork sources — an RDB snapshot timer and an AOF rewrite — can collide. Disabling RDB leaves one fork source, the AOF rewrite, scheduled by auto-aof-rewrite-percentage.

AOF everysec is one setting on a dial, not the end of it. Durability is a choice a system turns up or down, rung by rung: hold nothing in the volatile tier; keep an append-only log on the local volume with a bounded loss window; replicate the record off the box so a lost machine is not a lost record. The ~1s AOF bound is the second rung — the record survives a crash, but it lives on one machine's volume. The crash-timeline figure contrasts that bound with the snapshot interval.

The next rung is off-box. EchoStore.Graft is the native-BEAM replication engine: a single-writer VolumeServer commits pages to a local CubDB store, and EchoStore.Graft.Remote.Tigris ships segments and conditional commit objects to Tigris S3 in real time, behind a create-only commit fence so exactly one writer claims a slot. The commit drives the bus; the archive fold drives the commit. That is the frontier the AOF bound opens onto: the local log is rung two; commit-per-record replicated to Tigris is rung three. EchoMQ's job HASH is ~1s-loss-tolerant, so it sits on the AOF volume; a datum that cannot lose a second turns the dial further.