"Explain Redis persistence. When would you use RDB vs AOF?"
Persistence is the most common Redis follow-up question after threading. It tests whether you understand the durability-vs-performance tradeoff and whether you've operated Redis in production — recovery time, data loss tolerance, and fork-induced latency spikes are all real incidents teams have been through.
Open with the two modes: RDB takes point-in-time binary snapshots of the dataset; AOF appends every write command to a log file and replays it on startup.
Explain RDB: triggered by SAVE (blocking) or BGSAVE (forks a child). The child inherits the parent's memory via copy-on-write, so the snapshot is consistent. Compact binary file, fast recovery, but data since the last snapshot is lost on crash.
Explain AOF: every write is appended to disk according to the fsync policy — always (per command, safest, slowest), everysec (default, loses at most 1s), or no (let the OS flush). AOF rewrite compacts the log by replaying the current dataset.
Cover hybrid persistence (Redis 4+): the AOF rewrite dumps an RDB-format snapshot as the file prefix, then appends incremental AOF commands. Best of both — fast recovery and low data loss.
Warn about the fork cost: BGSAVE and AOF rewrite both fork the process. On large instances (tens of GB), the fork() system call itself can take hundreds of milliseconds and cause a latency spike. Transparent Huge Pages makes it worse.
Redis offers two persistence modes. RDB is a point-in-time snapshot — Redis forks a child process which serializes the entire dataset into a compact binary .rdb file. Thanks to copy-on-write, the parent keeps serving traffic while the child dumps memory, and only pages modified during the dump get duplicated. RDB files are small and recovery is fast — just mmap and load. The downside is data loss: anything written between snapshots is gone if the process crashes. AOF logs every write command to disk. The key knob is appendfsync — "always" fsyncs per command for near-zero data loss but kills write throughput, "everysec" is the production default and loses at most one second of data, and "no" lets the kernel decide. AOF files grow unbounded, so Redis periodically triggers AOF rewrite — it replays the current in-memory state to produce a minimal log, then swaps files. Since Redis 4, hybrid persistence combines both: the rewritten AOF starts with an RDB snapshot header for fast bulk load, then appends incremental commands for low data loss on crash. In production I'd enable hybrid mode — it gives RDB-speed recovery with AOF's durability. The big operational risk is fork latency. On an instance holding 30GB of data, copying the page table during fork() can freeze Redis for 200–500ms. Disable Transparent Huge Pages (THP), monitor latest_fork_usec, and avoid running BGSAVE during peak traffic.
Always mention copy-on-write — it's what makes BGSAVE possible without blocking.
Know all three appendfsync values and the exact data-loss guarantees of each.
For senior roles, mention fork-induced latency spikes and the THP disable recommendation.
Real interviews often follow up with "what did you pick in production and why" — have a concrete story ready, or use HireMe AI to surface a framework on the fly.
Use the redis-check-aof --fix tool. It truncates the last incomplete command. Data after the corruption point is lost.
Yes — set save "" and appendonly no. This is common for pure cache use cases where Redis is rebuilt from the source of truth.
RDB adds no write-path cost (happens in child). AOF with appendfsync=always is much slower; everysec is usually the right choice.
HireMe AI listens to your interview in real-time, detects questions, and generates instant answer suggestions — so you never freeze up again.
Try HireMe AI Free