Durability Architecture: The Transaction Log

How a Standard Redis Write Works

In standard Redis (including ElastiCache), the write path is simple and fast:

1. Client sends SET user:1 "Alice".
2. Primary node writes the value to its RAM.
3. Primary immediately responds OK to the client.
4. Asynchronously, the Primary replicates the change to Replica nodes.

The problem: steps 3 and 4 are decoupled. If the Primary crashes after step 3 but before step 4 completes, the Replica never received the write. The data is gone. This is called asynchronous replication lag, and it is an inherent trade-off in traditional Redis for the sake of write speed.

How a MemoryDB Write Works

MemoryDB inserts a mandatory synchronous step before acknowledging success:

1. Client write: Client sends SET user:1 "Alice".
2. Log first: The Primary node forwards this command to the Multi-AZ Transaction Log — a durable, distributed storage service managed by AWS, replicated across multiple Availability Zones.
3. Durable ACK: Only after the Transaction Log confirms the write is safely persisted across AZs does the Primary respond OK to the client.
4. RAM update: The Primary's in-memory state is updated (this likely happens in parallel with step 2, but the ACK waits for the log).
5. Replica sync: Replica nodes consume from the Transaction Log asynchronously to update their own in-memory state.

The critical guarantee: the ACK is the contract. If you received OK, your data is in the transaction log and will survive any single node or AZ failure.

The Latency Trade-off

This durability guarantee has a real cost:

Reads are identical — both serve from RAM. Writes are 5–10× slower in MemoryDB because of the mandatory network round trip to the transaction log. For most applications, single-digit millisecond write latency is still extremely fast. But for systems doing millions of writes per second where every microsecond counts, this is a meaningful architectural constraint.