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 below 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 child is writing the snapshot, every page the parent changes is copied, and memory use can rise noticeably. Redis 7 has RDB on by default: a snapshot is taken after an hour if at least 1 key changed, after 5 minutes if 100 changed, or after a minute if 10000 changed (save 3600 1 300 100 60 10000).

dump.rdbSAVE / BGSAVEsave 3600 1 300 100 60 10000

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. An AOF rewrite starts from a full snapshot in RDB format, and later write commands are appended in AOF format. Since Redis 7.0 these are separate files in the appendonlydir directory (one base file plus incremental files, tracked by a manifest); earlier versions kept them as the two halves of one file. 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. aof-use-rdb-preamble has been on by default since 5.0, so turning on AOF already gives you 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

A common setup turns on both: RDB files for periodic backups and for moving a dataset, and AOF with everysec to keep day-to-day loss small. AOF uses an RDB-format base file by default (hybrid persistence), so restarts stay fast. RDB alone fits data where losing a few minutes is acceptable. Which one you pick depends on restart time, the loss window and disk use. Either way, say what this is for: reducing loss, not turning Redis into the primary database.

← PreviousNext stop: write it yourself →