The Problem With Trusting RAM
Imagine you run a coffee shop and you keep your entire customer loyalty points ledger on a whiteboard. It's fast — you can read and update it in seconds. But if someone erases the whiteboard, all that data is gone forever. That's essentially what traditional Redis does: it stores everything in RAM, and RAM doesn't survive a power cut.
Redis is beloved for its speed — reads and writes complete in microseconds. But it was designed as a cache: a fast, temporary holding area that accelerates access to data that lives somewhere more permanent (like a relational database). The assumption was always that if Redis loses data, you can rebuild it from the real source of truth.
Amazon MemoryDB breaks that assumption on purpose. It is a Redis-compatible, durable, in-memory database — meaning it speaks the Redis protocol and API exactly, but it is engineered to be your primary database, not a sidecar cache.
What "Durable" Actually Means Here
In database engineering, durability is the "D" in ACID (Atomicity, Consistency, Isolation, Durability). A durable system guarantees that once a write is acknowledged as successful, that data will survive crashes, power failures, and even the loss of an entire data center.
Standard Redis on ElastiCache offers two persistence options:
- RDB (Redis Database Snapshots): Periodic point-in-time snapshots to disk. If Redis crashes between snapshots, you lose everything written since the last snapshot — potentially minutes of data.
- AOF (Append-Only File): Logs every write command to disk. More durable than RDB, but still has a configurable flush window (typically 1 second), meaning up to 1 second of data loss is possible.
MemoryDB eliminates this gap entirely. It guarantees RPO = 0 (Recovery Point Objective of zero), meaning zero data loss for any write that received a success acknowledgment, even if an entire Availability Zone fails simultaneously.
The Architectural Insight
MemoryDB achieves this by separating two concerns that traditional Redis conflates:
- Compute layer: The Redis engine running in RAM, serving microsecond reads.
- Storage layer: A distributed, multi-AZ transaction log managed by AWS that persists every acknowledged write to durable storage before confirming success.
This is the same architectural pattern used by Aurora (which separates the MySQL/PostgreSQL compute engine from its distributed storage layer). The Redis engine becomes stateless in a sense — it can be rebuilt from the transaction log at any time.