Append-Only File

AOF: durability by replaying history

RDB snapshots the state; AOF (Append-Only File) logs the operations that produced it. Instead of periodically dumping the whole dataset, every write command is appended to a log as it happens — recovery means replaying that log from scratch. This is the same idea as a write-ahead log (WAL) in a relational database, and it's the mechanism real Redis uses for near-zero data loss (versus RDB's "lose everything since the last snapshot" tradeoff).

The critical distinction: writes vs. reads

The entire feature hinges on correctly classifying every command your server supports as a write (mutates state — must be logged) or a read (doesn't — must NOT be logged):

GET, LRANGE, HGETALL, SMEMBERS, ZRANGE, EXISTS, TYPE, KEYS — none of these belong in this set. If you log a read command by mistake, replaying the AOF will still produce correct data (reads are no-ops against state), but it bloats the log and misrepresents what "AOF DUMP" should show a user auditing write history. Get the classification right rather than relying on it being harmless.

Hooking logging into your dispatcher

The cleanest place to log is a single choke point in your command dispatcher — not scattered if aof_enabled: log(...) calls inside every individual command handler:

Logging the original raw command line (not a re-serialized version) is important: it guarantees replay executes byte-identical commands, sidestepping any subtle differences between your internal representation and the wire format.

AOF ON / OFF / CLEAR

Note that AOF OFF stops future logging but must leave the existing log intact — turning logging off is not the same operation as clearing it.

AOF DUMP and AOF REPLAY

DUMP just prints what's there — no state changes:

REPLAY is the recovery path: wipe all current state, then re-run every logged command in original order, exactly as if a client had typed them fresh:

Order matters enormously here: if SET x 1 then SET x 2 are both logged, replaying them out of order silently corrupts the final value. Iterate the log exactly as appended (a plain Python list already preserves this).

Why this matters for the bigger project

AOF plus RDB are exactly how real Redis lets you trade off durability against performance and log size — small write-heavy workloads might fsync the AOF after every command, while snapshot-and-truncate strategies use RDB to keep the AOF from growing unbounded. Building both, even in simplified form, gives you a concrete feel for that engineering tradeoff rather than treating "persistence" as a black box.