Persistence & Durability

Redis

Chapter 8 · Persistence & Durability

💾 Persistence & Durability

Chapter 1 established that Redis is memory-first, with durability as an optional, configurable layer — not an automatic guarantee. This chapter covers the two real persistence mechanisms Redis offers, and the actual question that decides whether to bother with either: what is this specific data being used for?

Why Persistence Is Optional in Redis

By default, a Redis restart or crash loses everything — data lives in RAM, and RAM doesn't survive a power-off. Redis offers two distinct persistence mechanisms, each trading off differently between how much data could be lost and how much performance/complexity cost that protection carries.

RDB Snapshotting

RDB writes a compact, point-in-time snapshot of the entire dataset to disk, either on demand (SAVE, BGSAVE) or automatically at configured intervals.

# redis.conf — save a snapshot if at least 1 key changed in 900 seconds
save 900 1

# manually trigger a snapshot in the background (non-blocking)
127.0.0.1:6379> BGSAVE

RDB's file is small and restarts fast from it — but anything written since the last snapshot is lost if a crash happens in between, a real window of potential data loss.

AOF (Append-Only File)

AOF takes the opposite approach: every write command is logged to a file as it happens, and a restart replays the log to rebuild state. A configurable fsync policy trades durability against performance directly.

# redis.conf
appendonly yes
appendfsync everysec # fsync to disk roughly once per second — a common middle ground

always fsyncs on every single write (safest, slowest), everysec batches to about once per second (the usual default — at most ~1 second of writes at risk), and no lets the OS decide when to flush (fastest, least safe). AOF's log grows over time and is periodically compacted (BGREWRITEAOF) back down to a minimal representation of current state.

RDB vs. AOF

RDB

Compact single-file snapshots, fast restarts, good for backups — but a real data-loss window between snapshots.

AOF

Much smaller data-loss window (as little as ~1 second), larger file, slower restart while replaying the log.

Combining Both

Redis allows enabling both mechanisms together — a common real production setup: RDB snapshots for fast restarts and easy backup portability, AOF running alongside for the tighter data-loss window, each covering the other's weak point.

	RDB	AOF
Data-loss window	Since the last snapshot (minutes, typically)	As little as ~1 second (`everysec`)
Restart speed	Fast — loads one compact file	Slower — replays the full log
File size	Small	Larger, needs periodic rewriting
Best for	Backups, fast recovery	Minimizing data loss

When Redis Data Loss Is (and Isn't) Acceptable

The real decision isn't "which persistence setting is best" in the abstract — it's what is this Redis instance actually being used for, per Chapter 1's use-case table. A cache (Chapter 5) can be safely rebuilt from the real database after any restart — losing it is a non-event, since Redis was never the source of truth for that data in the first place. A queue or stream (Chapter 7) with no other durable record of its jobs is a different story entirely: losing unacknowledged work on a crash is a real, consequential loss.

Acceptable to Lose

A cache that can be repopulated from MySQL/MongoDB on the next request; session data that can force a re-login without real harm.

Needs Real Persistence

Queue/stream jobs with no other durable record; any case where Redis is genuinely the only copy of data that matters.

⚠️ Gotcha: Assuming Persistence Is On By Default

Coming from MySQL or MongoDB, where durability is automatic, it's an easy mistake to assume Redis is doing something similar unless told otherwise — Chapter 1 named this trade-off explicitly. Neither RDB save points nor AOF are guaranteed to be meaningfully configured out of the box on every install; a default local development setup may have far weaker persistence than production actually needs. Before treating any Redis instance as durable enough for a given use case, check redis.conf directly rather than assuming.

💻 Coding Challenges

Challenge 1: Choose a Persistence Strategy

For each, recommend RDB, AOF, both, or neither, and justify: (a) a pure cache in front of MySQL, (b) a Redis Streams-based job queue with no other durable record of pending jobs.

Goal: Practice applying "what is this data used for" to concrete scenarios rather than picking a setting in the abstract.

→ Solution

Challenge 2: Explain an fsync Policy Choice

Explain the difference between appendfsync always, everysec, and no, and why everysec is the common default middle ground.

Goal: Practice explaining the durability/performance trade-off each fsync setting represents.

→ Solution

Challenge 3: Diagnose a Surprising Data Loss

A team's Redis-backed job queue lost 10 minutes of unprocessed jobs after an unexpected server restart. They had RDB configured with save 600 1. Explain why this happened and what change would reduce the loss window.

Goal: Practice connecting an RDB save-point interval directly to a real observed data-loss window.

→ Solution

🎯 What's Next

The next chapter is Replication, Sentinel & Cluster — primary-replica setup, automatic failover, and sharding basics across nodes.