Persistence, replication and what a failover loses

Key points

• RDB is a point-in-time snapshot: compact, fast to load, and it loses everything written since the last save. AOF logs every write and loses at most one second with the default fsync policy.
• Running both is the usual production choice - AOF for recovery point, RDB for fast restarts and backups. On restart Redis prefers the AOF because it is more complete.
• appendfsync everysec is the sensible default. always is genuinely durable and slow; no leaves the decision to the kernel and can lose tens of seconds.
• Replication is asynchronous. The primary acknowledges a write before any replica has it, so a failover promotes a replica that may be missing recently acknowledged writes.
• WAIT blocks until N replicas confirm, which narrows the window but does not close it - and it costs latency on every call that uses it.
• Sentinel or Cluster handles the failover itself. The thing to configure carefully is min-replicas-to-write: it makes the primary refuse writes when too few replicas are connected, choosing unavailability over silent loss.

Example

# Both, which is what most production instances run.
save 900 1                    # RDB: after 900s if >=1 key changed
save 300 10
save 60 10000

appendonly yes                # AOF
appendfsync everysec          # always = durable+slow, no = up to 30s lost
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# Refuse writes rather than lose them silently:
min-replicas-to-write 1       # need >=1 connected replica to accept writes
min-replicas-max-lag 10
#   This chooses UNAVAILABILITY over DATA LOSS. That is a deliberate
#   trade and should be made consciously, not by default.

---
# THE WINDOW, concretely:
#
#   t=0    client: SET k v
#   t=1ms  primary applies it and replies OK        <- client believes it is saved
#   t=2ms  primary starts sending it to the replica
#   t=2ms  PRIMARY DIES
#   t=5s   replica promoted - it never received the write
#   -> an acknowledged write is gone, with no error anywhere

# Narrow it, at a latency cost, per call:
> SET critical:key value
> WAIT 1 100                  # block up to 100ms for 1 replica to confirm
(integer) 1                   # 1 replica has it; 0 means the timeout won

# Check the replication position:
> INFO replication
#   master_repl_offset:88123
#   slave0:...,offset=88123,lag=0     # equal offsets = fully caught up

---
# Choosing, honestly:
#
#   pure cache, rebuildable      RDB only, or nothing at all
#   sessions, tolerable loss     AOF everysec
#   queue or source of truth     AOF everysec + replicas + min-replicas-to-write,
#                                and seriously consider a real database

Replication is asynchronous, so a failover can drop acknowledged writes - min-replicas-to-write trades availability to prevent that.