In this chapter
We'll meet Redis's real persistence trade-off — RDB snapshots vs. the Append-Only File — and see exactly what a restart actually recovers under each.
The Problem in Real Life
The flash sale is over. Everything worked — the counters, the lock, the queue, the leaderboard. Mike asks the one question that's been sitting underneath this entire Act since the first chapter.
Redis keeps everything in memory. Memory doesn't survive a restart on its own.
So what happens to all of it if the Redis server just... restarts?
Mike
What Survives a Restart, and What Doesn't
In-memory means gone on restart, by default
Without persistence enabled, a Redis restart loses everything — a real, deliberate risk, not a hidden one.
RDB vs. AOF — a real trade-off
Snapshots are fast to restore but can lose recent writes; an append-only log loses far less, at a real ongoing cost.
Persistence & Durability
By default, Redis is exactly as risky as Mike suspects: purely in memory, gone on a crash. Two optional mechanisms fix that, and each costs something different to get it.
- Persistence is Redis's umbrella term for any mechanism that writes in-memory data to disk so it survives a restart. It's opt-in, not automatic — a plain Redis instance with neither mechanism enabled is a pure, disposable cache, and for many real uses (a session cache in front of a real database that still holds the actual data) that's a deliberate, acceptable choice, not an oversight.
- RDB snapshots write the entire dataset to disk at set intervals (say, every 5 minutes, or after a set number of writes). Restoring from an RDB file is fast — Redis just loads the snapshot back into memory — but anything written since the last snapshot is genuinely, permanently lost if a crash happens in between.
- AOF (Append-Only File) takes the opposite approach: it logs every write command as it happens, in order. Recovering means replaying that log — far less data loss on a crash, often close to none, at the cost of writing to disk on every single write, which eats into exactly the raw speed this whole Act has been built around.
Neither option is strictly better. RDB is fast to restart from and cheap to run, but honest about losing recent writes. AOF is far safer, but pays for it continuously, not just during a crash.
Key Takeaway
Redis's speed was never free — it's borrowed against durability, and persistence is the deliberate, honest way to decide how much of that borrowed durability GreenMart wants back, and at what ongoing cost.
Why This Matters
This closes the loop the very first chapter of this Act opened: Redis is fast because it lives in memory, and memory has a real, honest cost that only shows up when something goes wrong. Every production Redis deployment makes this exact choice — this chapter is what makes it an informed decision instead of an unpleasant surprise during an actual outage.
GreenMart now knows exactly what a Redis restart recovers, and why. The next chapter asks a related but separate question: what happens if the whole machine, not just the process, goes away?