Redis appendfsync always latency: durability vs throughput trade-offs

Redis AOF persistence logs every write to disk, but the appendfsync policy controls how aggressively Redis forces that log to physical storage. That choice defines whether a crash loses zero, one, or sixty seconds of data, and whether a single slow disk seek can freeze the entire event loop.

appendfsync always on slow storage degrades throughput more severely than dataset growth. appendfsync no on a critical ledger silently exposes you to massive data loss.

The policy is the boundary between durability and latency. This article covers the mechanics of the three fsync modes, their production failure modes, and the signals that reveal disk I/O saturation.

What it is and why it matters

The Append Only File (AOF) reconstructs the dataset on startup by replaying writes. Before acknowledging a write, Redis appends it to the AOF buffer and, depending on policy, may force the kernel to flush that buffer to disk. Because Redis runs commands on a single main thread, a synchronous flush blocks every other client. The appendfsync directive controls this flush behavior, trading durability for main-thread latency.

How it works

Redis supports three fsync policies.

With appendfsync always, the main thread writes to the AOF file

[OUTPUT TRUNCATED: Response exceeded output token limit.]