Building a Durable In-Memory Database with Amazon MemoryDB for Redis - Unifying Cache and Primary Data Store
Learn how to operate a Redis-compatible in-memory database with MemoryDB, understand its durability mechanisms, and decide when to use it versus ElastiCache.
Overview of MemoryDB
MemoryDB for Redis is a durable in-memory database service compatible with Redis 7.x, capable of storing up to hundreds of terabytes of data across up to 500 nodes. While ElastiCache for Redis is specialized for caching (volatile data), MemoryDB guarantees write durability through a Multi-AZ transaction log, making it suitable as a primary data store. Read latency is in the microsecond range, and write latency is in the single-digit millisecond range. In cluster mode, it scales out to up to 500 shards, each consisting of a primary and up to 5 replicas.
How Durability Works
MemoryDB synchronously records writes to a Multi-AZ transaction log, ensuring no data loss during node failures. Write operations return an ACK to the client only after persistence to the transaction log is complete, guaranteeing strong consistency. On node restart, data is fully restored from the transaction log, resulting in zero data loss compared to snapshot-based recovery. Replication to replica nodes is asynchronous, so reads from replicas are eventually consistent. In addition to daily automatic snapshots (retained up to 35 days), manual snapshots can be taken and used as a base for point-in-time recovery.
Use Cases and When to Choose Over ElastiCache
MemoryDB is well suited for use cases that need in-memory speed without risking data loss, such as session stores, user profiles, leaderboards, and real-time analytics. You can take full advantage of Redis data structures (Sorted Sets, Hashes, Streams) and position MemoryDB as a data layer that complements DynamoDB or RDS. ElastiCache is better suited as a front-end cache for RDS or DynamoDB, where some data loss is acceptable. ElastiCache uses asynchronous replication, which means recent writes may be lost during failover. As a selection criterion: if the data can be re-fetched from the source (such as RDS), choose ElastiCache; if the data in Redis is the sole source of truth, choose MemoryDB. Using MemoryDB as a cache is overengineered and more expensive, so it should be avoided. To deepen your knowledge of database design, specialized books on Amazon can be a valuable resource.
Redis Data Structures and Server-Side Processing
MemoryDB fully supports the Redis 7.x command set, including Strings, Hashes, Lists, Sets, Sorted Sets, Streams, HyperLogLog, and Geospatial indexes. Sorted Sets are effective for implementing leaderboards and timelines with O(log N) ranking retrieval. Streams can serve as event logs or message queues with consumer group support for parallel processing. Lua scripting enables atomic server-side processing, Redis Functions allow registration of reusable logic, Pub/Sub provides real-time notifications, and transactions (MULTI/EXEC) support atomic operations. ACL v2 enables fine-grained access control per user and per command, with the ability to separate read and write permissions by key pattern. In cluster mode, data is distributed based on hash slots following the Redis Cluster protocol, and clients automatically connect to the correct shard via MOVED redirects. Large keys (several MB or more) concentrated on a single shard can cause hot spots, making uniform key size an important data model design consideration.
Design Best Practices and Considerations
With MemoryDB, it is critical that your data size fits within node memory. High memory utilization causes swapping or eviction that degrades performance, so plan capacity to keep utilization below 75%. Shard count changes (resharding) can be performed online, but write latency temporarily increases during data redistribution. Encryption is supported both at rest (KMS) and in transit (TLS), and ACLs (Access Control Lists) provide command-level authorization control. The standard architecture places MemoryDB in a VPC with security groups restricting source connections. Multi-AZ is enabled by default, providing high availability without additional configuration.
Pricing and Limit Considerations
A db.r7g.large MemoryDB node costs approximately $0.463 per hour (about $333 per month). This is roughly 20% more expensive than an equivalent ElastiCache node, but includes transaction log storage for durability. Data transfer within the same region is free, while cross-region transfer follows standard data transfer pricing. Snapshot storage beyond the free tier (equal to the node's memory size) costs approximately $0.085 per GB per month. Reserved nodes (1-year/3-year) can reduce costs by up to approximately 55%. Key limits include a maximum of 500 shards per cluster, 5 replicas per shard, and configurable eviction behavior via the maxmemory-policy parameter group setting.
Summary
MemoryDB is a Redis-compatible in-memory database with guaranteed durability. It achieves write persistence through a Multi-AZ transaction log, and unlike ElastiCache (which is designed for caching), it can serve as a primary database. With microsecond read latency, it is an excellent data layer for session stores, leaderboards, and real-time analytics. The key design principle is a clear separation: ElastiCache for caching, MemoryDB when the data stored is the sole source of truth.