A team wants to use Redis as the system of record for data with monetary value. What durability posture would you configure, and what would you tell them they can still lose?

## Start by refusing the vague version of the question "Make Redis durable" is not actionable. Two numbers make it so: - **RPO** (recovery point objective): how much recent data may be lost, per failure class. Process crash, power loss, node loss with failover and whole-region loss are four different numbers, and Redis behaves differently in each. - **RTO** (recovery time objective): how long the service may be down while recovering. This is where AOF size and load time enter, since restoring a large instance is minutes of replay, not seconds. A principal-level answer produces those numbers, then configures to meet them, rather than reciting settings. ## The configuration I would set **Local durability.** `appendonly yes`. `appendfsync everysec` as the default, because it bounds power-loss exposure at roughly one second at very little throughput cost. `appendfsync always` only when the workload's write rate and the storage device can absorb a synchronous flush per event-loop iteration; on network-attached storage this is often an order-of-magnitude throughput cut, so it must be measured, not assumed. Keep `aof-use-rdb-preamble yes` so the base loads fast, which is an RTO decision. **Snapshots for restore, not for durability.** Regular `BGSAVE` on a replica, shipped off-host with timestamped names, retention, and periodic rehearsed restores. AOF bounds the loss window; snapshots are what you use when someone runs the wrong command or the volume is gone. They answer different questions and you need both. **Redundancy across failure domains.** Replicas on different hosts, ideally different availability zones, each with its own persistence so a correlated restart does not come back empty. Automated failover via Sentinel or Cluster, configured with `min-replicas-to-write` so a partitioned master stops accepting writes it cannot replicate, which converts silent data loss into visible unavailability. Choosing that direction is a real decision to state out loud. **Host prerequisites.** `vm.overcommit_memory=1`, transparent huge pages off, and `maxmemory` low enough that dataset plus copy-on-write fits RAM. Persistence that cannot fork is persistence that is not happening; the failure is silent and shows only in `aof_last_bgrewrite_status` and a growing file. ## What they can still lose, stated plainly 1. **Up to about a second on power loss** with `everysec`, and more when the disk is lagging, which `aof_delayed_fsync` reveals. With `always`, an acknowledged write is fsynced first, though a device or controller with a volatile write cache can still acknowledge early. 2. **Acknowledged writes on failover.** This is the important one. Redis replication is asynchronous: the master replies to the client and streams to replicas afterwards. Promote a replica after a master dies and every write not yet shipped is gone, no matter how aggressively the master fsynced locally. No `appendfsync` value fixes this, because it is a distributed-systems property, not a disk property. 3. **Logical destruction.** `FLUSHALL`, a bad migration, or an application bug replicates to every replica within milliseconds. Only off-host snapshots, and ideally immutable ones, cover this. 4. **Time to recover.** A large AOF takes minutes to load. If the RTO is 30 seconds, persistence alone does not meet it; you need a warm standby. ## The tools that narrow the failover gap, and their limits `WAIT numreplicas timeout` blocks the calling client until N replicas have acknowledged the writes issued so far, returning how many did. Redis 7.0 added `WAITAOF numlocal numreplicas timeout`, which waits for the local AOF fsync and for replica fsyncs. Both are genuinely useful for the small subset of writes that truly must be confirmed, and both cost a round trip of latency on those writes. What they are not: synchronous commit. They confirm *after* the write was applied and acknowledged, they do not roll anything back if the confirmation fails, and they cannot help if the acknowledging nodes fail together. Presenting `WAIT` as making Redis a durable database is a red flag. ## The architectural recommendation For monetary data, I would place a durable, transactional store as the authority and use Redis for what it is exceptional at: latency, throughput and expressive data structures. Concretely, either write to the durable store first and use Redis as a cache and index, or write to Redis for speed and stream to durable storage with a reconciliation process that can rebuild Redis and detect divergence. Idempotency keys make the replay safe. If the team's constraint makes Redis genuinely the only store, then the deliverable is honesty in writing: the RPO per failure class, the RTO measured on real data, the alerting on persistence health (`aof_last_write_status`, `aof_last_bgrewrite_status`, `aof_delayed_fsync`, disk free space, replication lag), rehearsed failover and restore procedures, and explicit sign-off from whoever owns the money that a one-second and a failover-sized loss window are acceptable. A managed or enterprise offering with stronger replication guarantees is a legitimate part of that conversation, but it should be evaluated on the guarantees it documents, not on its marketing. ## How to close The strong answer names the residual risk before being asked. "With this configuration you lose at most about one second on a power cut, an unbounded amount on an ungraceful failover, and everything on a logical wipe unless we hold immutable off-host snapshots" is the sentence that distinguishes someone who has operated this from someone who has read the configuration file.