RedisVisualRedis in production

Stop 5 · Redis in production

Four mechanisms you only meet once Redis is running in production: persistence, expiry and eviction, availability and scaling, and transactions. What each one does, and what it does not promise.

Start here

The earlier stops covered what Redis is and how to use it; this one covers what happens in production

By now you can use as a cache. Running it in production raises four more questions. What happens to the data in after a restart or a power cut (persistence)? What happens to a key once its TTL has passed, and which keys are removed when memory fills up (expiry and eviction)? What happens when one machine fails, or when one machine is no longer enough (availability and scaling)? And how do several commands run as one unit (transactions and atomicity)? Once Redis is on your resume, these are the questions an interviewer asks next. Open the tabs one at a time — each has an animation, a comparison table, and a few interview questions.

keeps data mostly in , and memory is empty again after a restart or a power cut. Persistence writes that data to disk, so a restart can load it back. There are two approaches: RDB writes periodic snapshots, and AOF logs every write command. Neither one makes Redis a durable primary database by default.

RDB · snapshot
dump.rdb
one full copy, at intervals
AOF · append log
›SET a 1›INCR a›LPUSH q x›SET b hi›DEL a
each write appended to the end
Left: RDB writes the whole dataset to one file at intervals. Right: AOF appends each write command to the end of a log that keeps growing.
The mechanism

RDB · snapshot

RDB writes a point-in-time snapshot of the whole dataset to one compact binary file (dump.rdb). The file is small and loads quickly, which makes it good for backups and for moving a dataset to another machine. The cost is data loss: if Redis stops between two snapshots, every write made after the last snapshot is gone. BGSAVE also forks a child process to write the file. Parent and child share copy-on-write, so while the parent keeps accepting writes during the fork, memory use can rise noticeably.

dump.rdbSAVE / BGSAVEsave 900 1

AOF · append-only file

AOF (append only file) appends every write command to the end of a log. On restart, Redis replays that log from the beginning to rebuild the data. The fsync policy is set by appendfsync and has three values. always fsyncs after every command: the safest and the slowest. everysec fsyncs once a second: the default, and it can lose about one second of writes in a crash. no leaves the timing to the operating system: the fastest and the least safe. Compared with RDB, AOF loses less and the log is readable, but the file is larger and recovery is slower because the commands run again. An AOF rewrite compacts the log into the shortest set of commands that produces the same data, so it does not grow forever.

appendonly yesappendfsync everysecBGREWRITEAOF

Hybrid persistence (Redis 4.0+)

This combines the two. The AOF file begins with a full snapshot in RDB format and appends the later write commands after it. On restart, Redis loads the snapshot quickly and then replays a short tail of commands, so recovery is faster than plain AOF and the loss window is smaller than plain RDB. Many production setups use this combination.

aof-use-rdb-preamble yes

Recoverable is not the same as durable

Persistence lets Redis load its data again after a restart, but neither RDB nor AOF makes it a durable primary database by default. RDB loses everything written after the last snapshot, and the default AOF policy can lose about one second of writes. So treat Redis as a layer you can rebuild: for money and other critical state, keep the authoritative copy — the — in the database. In an interview, saying that limit out loud is worth more than naming config options.

Side by side
DimensionRDB snapshotAOF log
Recovery speedFast: loads a binary fileSlower: replays the commands
File sizeCompactLarger: one entry per write
Data lossMore: everything after the last snapshotLess: about one second with everysec
Best forBackups, moving a dataset, fast restartKeeping the loss window small
Interview probes
Answer

You lose every write made after the last snapshot. Snapshots are periodic: if one is taken every 5 minutes, a crash between two snapshots loses up to those 5 minutes of writes. RDB on its own fits cache-like data where losing a few minutes is acceptable. Data you cannot afford to lose needs more than this.

Answer

It sits between safety and speed. always fsyncs after every command: the safest, but it turns each write into a disk write, which is slow. no leaves everything to the operating system: the fastest, but it can lose much more. everysec fsyncs once a second in the background and loses about one second of writes in a crash. Most workloads accept that, and the cost is small, so it is the default.

Answer

Two setups are common. One is RDB for periodic backups plus AOF everysec as the main persistence: you get a compact snapshot you can copy elsewhere, and day-to-day loss stays small. The other is hybrid persistence, where an RDB snapshot and the later commands live in the same AOF file. That restarts faster and still loses little. Which one you pick depends on whether restart time or the loss window matters more. Either way, say what this is for: reducing loss, not turning Redis into the primary database.

← PreviousNext stop: write it yourself →