Design and Performance of Amazon MemoryDB: A Fast and Durable Memory‑First Cloud Database

Recently the author read the Amazon MemoryDB paper titled "Amazon MemoryDB: A Fast and Durable Memory‑First Cloud Database" and recorded the key points of the design.

MemoryDB is built on Redis and aims to address Redis's shortcomings in data consistency and durability, positioning itself as a database rather than a cache for write‑intensive, latency‑sensitive scenarios such as IoT, finance, and advertising.

The core contribution of the paper is a distributed log system that replaces the traditional master‑to‑replica push model: writes are first recorded in a distributed transaction log, and replicas actively pull changes, enabling strong consistency and reliable persistence.

Developed in 2021, MemoryDB minimizes changes to upstream Redis code, focusing modifications on the replication path. The write‑and‑sync workflow consists of:

Key changes are written to a tracking buffer (tracker) and the client is blocked until the change is acknowledged by the distributed log.

The change is committed to a multi‑AZ distributed transaction log.

After the log ACK, the primary applies the buffered changes, making them visible to the client.

Replicas asynchronously pull and replay the changes to achieve eventual consistency.

Strong consistency is guaranteed when reads are restricted to the primary; reads from replicas provide only eventual consistency. Because Redis processes commands single‑threadedly, the order of log writes is preserved, and MemoryDB enforces that a read must wait for the corresponding log entry to be committed before returning a value.

Example: Client A issues SET A 2 and waits with WAIT . Before the log ACK, Client B's GET A would see the new value in vanilla Redis, but MemoryDB blocks the read until the log is committed, preventing the anomaly.

For data recovery, MemoryDB periodically creates snapshots (RDB) that store the log offset. On restart, the snapshot is loaded and the log is replayed from the stored offset, reducing replay time compared to a full log replay.

Performance comparison shows MemoryDB achieving higher read‑only throughput (up to 500K ops/s on large instances) than open‑source Redis (≈330K ops/s), while write throughput is roughly half of Redis due to the extra log round‑trip. Latency measurements indicate similar read latency (P50/P99) but higher write latency (P99 ≈ 6 ms vs. 3 ms for Redis). BGSAVE introduces occasional latency spikes due to fork‑copy‑on‑write overhead.

The paper also discusses slot migration and leader election improvements: leader election no longer relies on the Cluster Bus but uses a Raft‑like lease mechanism, and slot migration serializes keys before transferring them to the target node.

Overall, MemoryDB demonstrates how a distributed transaction log can enhance Redis's consistency and durability at the cost of some performance, offering valuable design insights for building memory‑first cloud databases.