Why this matters
- VaultCommerce treats Redis as a cache first — cold restart repopulates from Postgres. Still, session tokens and rate-limit state hurt if wiped unexpectedly.
- Misconfigured AOF rewrite or RDB saves during peak traffic causes latency spikes on the single command thread.
- Managed Redis (ElastiCache, Memorystore) hides file paths but you still choose persistence tier and failover behaviour.
RDB snapshots
RDB writes the full dataset to a .rdb file on a schedule or after N changes. Restore loads the file back into memory — fast startup, but you lose writes since the last snapshot.
# redis.conf excerpts
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis
BGSAVE
LASTSAVE
INFO persistence | grep rdb
RDB trade-offs
- Pros — compact files, quick restarts, minimal steady-state overhead.
- Cons — data loss window equals time since last snapshot.
- Ops note —
BGSAVEforks the process; large datasets mean copy-on-write memory pressure.
VaultCommerce accepts minutes of session loss on a pure cache node and enables RDB every 5 minutes — not every second.
AOF append-only file
AOF records mutating commands. On restart Redis replays the log to rebuild state. appendfsync controls durability vs throughput:
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec # always | everysec | no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
CONFIG GET appendfsync
BGREWRITEAOF
INFO persistence | grep aof
everysec fsyncs once per second — at most ~1 s of writes lost on crash. always fsyncs every write — safest, slowest.
Combining RDB + AOF
Redis can use both: RDB for baseline snapshots and AOF for recent writes. After a crash, Redis prefers the AOF if enabled. For VaultCommerce's session store tier, AOF with everysec balances durability and latency.
# Verify effective persistence mode
redis-cli INFO persistence
When persistence is optional
Pure cache-aside layers rebuild from Postgres on miss — disable persistence entirely for lowest latency. Keep persistence when losing keys has user-visible impact (sessions, idempotency tokens, rate-limit windows).
Quick recall
Everything you need if you only revisit this box.
- RDB: periodic full snapshots — fast restore, bounded data-loss window.
- AOF: command log with configurable fsync — finer durability, larger files.
appendfsync everysecis the common production compromise.- Background rewrite/save forks memory — plan capacity before peak traffic.
- VaultCommerce: no persistence on product cache; AOF on session tier.
- Managed services abstract files but persistence tier still affects RPO.
Test yourself
Answer these before moving on — recall is what makes it stick.