You operate three Redis deployments: a page-fragment cache, a user session store, and a small ledger of business events that no other system holds. For each, decide whether to run snapshots only, the append-only file only, or both — and justify the configuration you would set.

## The three questions that decide the configuration Before touching `redis.conf`, answer these: 1. **If this instance loses everything right now, where does the data come back from?** If the answer is "the database" or "the user just logs in again", you are choosing for convenience. If the answer is "nowhere", you are choosing for survival. 2. **How much loss is acceptable, in seconds or minutes?** That number picks between save points (minutes) and an fsynced command log (about a second). 3. **How fast must it come back?** Recovery time drives whether the append-only file carries an RDB body and whether you fail over to a replica instead of reloading. The mechanisms map cleanly onto those answers. Snapshots (`save <sec> <changes>`, `BGSAVE`) give you a compact, checksummed, point-in-time file that is trivial to copy off the box — a great *backup artifact*, a poor *durability guarantee*, because everything since the last one is gone. The append-only file gives you a fine-grained loss window set by `appendfsync`, at the cost of a bigger file and, historically, slow command-replay recovery — which is exactly what `aof-use-rdb-preamble yes` fixes by making the AOF base a binary snapshot. ## Deployment 1: page-fragment cache The origin service can regenerate every value. Persistence contributes only a warm start after a restart, which shortens the post-restart latency spike and origin load. Reasonable configuration: `appendonly no`, with modest save points (or none if you prefer a cold start). Note the real cost of keeping snapshots here is not disk, it is the fork: a write-heavy cache snapshotting frequently pays copy-on-write memory and a fork pause. Many teams run caches with persistence fully disabled (`save ""`) and accept the cold start, especially when `maxmemory` is set near the box limit and the copy-on-write headroom does not exist. If you do keep save points, also keep `stop-writes-on-bgsave-error` in mind: with it at the default `yes`, a failing background save makes Redis reject writes with `MISCONF`. For a pure cache that is usually the wrong trade — a cache should keep serving even if it cannot persist — so this is one of the few places where turning it off is defensible. ## Deployment 2: session store Sessions are re-creatable but only by inconveniencing every user at once. A restart that drops them is a visible incident; losing a few seconds of newly created sessions is not. Configuration: `appendonly yes`, `appendfsync everysec`, `aof-use-rdb-preamble yes`, plus save points retained so you still produce a `dump.rdb` for backups. This is the canonical "run both" case. The AOF bounds the loss window to roughly a second, the RDB body inside it keeps restart fast, and the separate snapshot is what your backup job ships off the machine. Add a replica so that a node failure is a failover rather than a reload, and remember that sessions usually carry TTLs — expirations are recorded in both formats, so a restore does not resurrect long-dead sessions. ## Deployment 3: business-event ledger Here the honest senior answer starts with a challenge to the premise. Redis's durability story is bounded: `appendfsync always` fsyncs per event loop iteration, which tightens the local window but costs throughput and still cannot survive disk loss; replication is **asynchronous**, so a primary can acknowledge a write and fail before any replica has it; and automatic failover promotes a replica that may be behind. `WAIT` can block until N replicas acknowledge, which raises confidence but is not a consensus commit. So: run both persistence mechanisms (`appendonly yes` with `everysec` or `always` depending on measured throughput, preamble on, save points on), take snapshots off-box on a schedule, keep replicas — and either mirror the events into a store designed to be a system of record, or accept and document the failure modes in which Redis loses acknowledged data. Choosing Redis as the sole home for irreplaceable data is a decision to defend explicitly, not a configuration detail. ## The decision heuristic to state out loud - Rebuildable data → snapshots only, or nothing. - Painful-but-survivable loss → both, `everysec`, preamble on. - Irreplaceable data → both, plus replicas, plus off-box backups, plus a second system — and be explicit about what Redis still cannot promise. Also keep the operational asymmetry in view: AOF-only is an unusual choice because you give up the cheap, portable snapshot artifact for backups and disaster recovery while gaining nothing on durability that both-enabled does not already give you. When someone proposes AOF-only, the usual real motivation is avoiding a second fork for save points on a memory-tight box — which is a capacity conversation, not a durability one.