RDB Snapshots

RDB: point-in-time snapshots

Everything you've built so far lives in memory — restart the process and every key vanishes. Real Redis offers two durability strategies: RDB (periodic full snapshots) and AOF (append-only command log, covered next lesson). This lesson builds a simplified RDB: a compact text serialization of the entire dataset that can be dumped and reloaded.

Designing the serialization format

Unlike real RDB (a binary format with length-prefixed encoding, checksums, and version headers), this exercise uses a readable line-per-key text format so you can eyeball correctness directly:

KEY string mykey myvalue
KEY list mylist a,b,c
KEY hash user name=Alice,age=30
KEY set tags red,blue,green

Each value type needs its own encoding rule for how internal structure gets flattened onto one line. Notice the pattern: lists and sets join elements with commas; hashes join field=value pairs with commas. This is a classic serialization tradeoff — simple and human-readable, at the cost of breaking if a stored value itself contains a comma or =. Real RDB avoids this with explicit length prefixes instead of delimiters; it's worth noting the limitation even though this exercise's test data won't hit it.

SAVE: walking every store, sorted

Sorting keys before emitting them is what makes SAVE's output byte-for-byte comparable in a test — without it, dict iteration order could vary and break assertions that expect a specific line ordering.

RESTORE: parsing back into live stores

RESTORE has to reverse each encoding rule exactly, splitting on the same delimiters:

line.split(" ", 3) is important: it limits the split to 4 parts total, so the value portion (which might itself contain spaces, e.g. "hello world") isn't chopped up further. The same care applies to pair.split("=", 1) for hash fields whose value might contain =.

What SAVE/RESTORE means for the rest of your server

Once this works, DBSIZE and every read command (GET, LRANGE, HGETALL, ...) must transparently see restored data — because RESTORE populates the same underlying stores every other command reads from, this should require zero changes to those commands if your data model is consistent. If you find yourself needing to special-case "restored" keys anywhere else, that's a signal your stores aren't as unified as they should be.