Append Only File persistence takes the opposite approach from RDB. Instead of saving the current dataset as a snapshot, AOF records the write operations that change it.

The shape is:

write command -> append to log -> fsync according to policy -> replay at startup

On recovery, Redis starts with an empty dataset and replays the log until memory reflects the saved command stream.

Why AOF Exists

RDB is compact and fast to load, but it can lose writes since the most recent snapshot. AOF narrows that window by recording writes as they happen.

Redis exposes durability tradeoffs through fsync policy:

always    sync every write, strongest and slowest
everysec  sync roughly once per second, common compromise
no        let the operating system flush when it chooses

The policy determines how much data may be lost if the process or machine crashes. More durability usually means more I/O cost.

The Log Contains Mutations

Read commands do not belong in AOF. A GET changes no dataset state. A SET, DEL, HSET, or EXPIRE does.

The log is usually written in a Redis protocol-compatible form so replay can use the same command machinery. That is elegant because Redis already knows how to parse and execute commands.

Expiration needs care. A relative expiration such as "expire in 60 seconds" may need to be represented in a way that preserves meaning after downtime. Absolute expiration forms avoid resurrecting keys for a fresh 60 seconds during replay.

Ordering And Acknowledgement Are Subtle

Persistence sits between command execution and client acknowledgement. If Redis executes a write but crashes before it reaches durable storage, the client may believe a write succeeded even though it does not survive restart. If Redis waits for strong fsync on every write, latency rises.

AOF policy is therefore an explicit tradeoff between throughput, latency, and crash-loss window.

The important point is not that one policy is universally correct. It is that durability is not free, and Redis lets operators choose the cost profile.

AOF Rewrite

An append-only file grows forever unless compacted. If a key is set 10,000 times, the final dataset only needs the last value, but the raw AOF may contain every intermediate command.

AOF rewrite creates a shorter equivalent command sequence from current state:

current dataset:
  counter = 42

long old AOF:
  SET counter 1
  INCR counter
  INCR counter
  ...

rewritten AOF:
  SET counter 42

The rewritten file is not a faithful user-command history. It is a compact program that recreates the same current dataset.

During rewrite, Redis must also capture writes that happen while the new file is being produced, then combine the rewritten base with the incremental tail safely.

AOF And RDB Together

RDB and AOF are not enemies. They answer different persistence questions.

RDB: compact image of state
AOF: append log of mutations

Modern Redis deployments may use them together or use hybrid AOF formats that combine a base snapshot with an incremental command log. The goal is to balance restart speed, file size, and data-loss tolerance.

AOF is the persistence mode for people who want Redis to remember not just a recent picture of memory, but the writes that happened after that picture would otherwise be stale.