Ace Cloud Interviews
🗃️

AWS Database

MemoryDB

Redis-compatible in-memory database with multi-AZ durability

Amazon MemoryDB for Redis is a Redis-compatible in-memory database with multi-AZ durability. Unlike ElastiCache which uses Redis as a cache in front of a durable database, MemoryDB stores data durably in a distributed transaction log across multiple AZs - Redis is the primary database, not just a cache. MemoryDB provides the full Redis data structure API with microsecond read latency, single-digit millisecond write latency, and strong consistency guarantees that make it suitable as a primary database rather than a caching layer.

MemoryDB vs ElastiCache Redis: The Critical Distinction

The fundamental difference is durability. ElastiCache Redis can lose data on failure even with Multi-AZ - the standby is eventually consistent. MemoryDB writes to a Multi-AZ transaction log before acknowledging a write, guaranteeing data survives node failures.

AttributeElastiCache RedisMemoryDB for Redis
Primary purposeCache in front of a durable databaseDurable primary database with Redis API
DurabilityIn-memory; data may be lost on failureMulti-AZ transaction log; survives node failures
Write acknowledgementAfter write to primary memoryAfter write committed to transaction log across AZs
Read latencyMicrosecondsMicroseconds (same)
Write latencySub-millisecondSingle-digit millisecond (transaction log overhead)
Data loss on failurePossible (seconds of data if replica not yet synced)Zero (transaction log is durable)
ConsistencyEventual (async replication to replicas)Strong (synchronous transaction log)
CostLower~20-30% higher due to transaction log
Use as primary DB?No - use with a durable backendYes - designed for this use case
💡

If you are using ElastiCache Redis as your only data store (no backing database), you should be using MemoryDB instead. ElastiCache is a cache; MemoryDB is a durable database. Using ElastiCache as a primary database risks data loss on instance failure.

Cluster Architecture: Shards, Nodes, and the Transaction Log

A MemoryDB cluster is made up of shards. Each shard has a primary node and up to 5 replica nodes. The transaction log is replicated across all AZs before a write is acknowledged.

ComponentDescriptionKey Detail
ShardA horizontal partition of the keyspaceUp to 500 shards per cluster
Primary nodeHandles writes and reads for the shardOne per shard
Replica nodeRead-only copies for read scaling and failoverUp to 5 per shard; distributed across AZs
Transaction logMulti-AZ durable commit log for writesWritten before primary ACKs; powered by AWS-managed service
Cluster endpointEntry point for all cluster operationsCluster-aware client required
💡

MemoryDB requires a cluster-aware Redis client (most modern Redis clients support cluster mode). The keyspace is hash-slot based (16,384 slots distributed across shards), identical to Redis OSS Cluster mode.

Use Cases: When MemoryDB Is the Right Choice

Use CaseWhy MemoryDBAlternative
Gaming leaderboardsRedis sorted sets with microsecond reads; durable rankingsElastiCache + RDS (two databases to manage)
Session store (no backing DB)Sessions durable without separate RDBMSElastiCache (risk data loss) or RDS (slower)
Rate limitingAtomic Redis INCR operations; durability for billing-critical limitsElastiCache acceptable if approximate limits OK
Real-time inventory / countersAtomic operations; microsecond reads; durable countsDynamoDB (slower) or ElastiCache (not durable)
Message queues (Redis Streams)Durable streams with consumer groupsElastiCache (stream may lose messages on failure)
Financial account balancesStrong consistency; durability; atomic operationsRDS (slower but full ACID)
⚠️

MemoryDB is not a replacement for PostgreSQL or DynamoDB for complex relational or document workloads. It excels at high-speed, simple data structures where microsecond access matters and durability is required. For complex queries, JOINs, or document storage, use the appropriate specialized database.

Snapshots, Security, and Redis API Compatibility

FeatureDetail
SnapshotsAutomatic daily snapshots; manual on-demand; stored in S3 managed by AWS
RestoreCreate a new cluster from a snapshot
Encryption at restAES-256 via AWS-owned or customer KMS key
Encryption in transitTLS required; cannot disable
AuthenticationACL-based users (username + password); IAM auth not supported
Redis version supportRedis 6.2 and 7.x; full ACL and module support
Redis modulesLimited - no third-party modules (RedisSearch, RedisGraph, etc.)
💡

MemoryDB uses Redis ACLs for access control. Create separate ACL users with restricted command sets and key patterns for each application component - do not share a single superuser across all services.

Pricing Model

ComponentPricing BasisTip
Node hoursPer hour by node type (db.r6g, db.r7g, etc.)Reserve production clusters for savings
StoragePer GB-month of data stored (in-memory + transaction log)Size appropriately; no cold tier unlike Timestream
Snapshot storagePer GB-month beyond free allowance (1x data size free)Reduce retention for non-production clusters
💡

MemoryDB is priced roughly 20-30% higher than equivalent ElastiCache Redis nodes to cover the transaction log infrastructure. For workloads where you would otherwise run ElastiCache + a durable database, MemoryDB is often cheaper and simpler in total cost of ownership.

🎯

Interview Focus Points

  • 1What is the difference between MemoryDB for Redis and ElastiCache Redis?
  • 2When would you choose MemoryDB over ElastiCache as a data store?
  • 3How does MemoryDB achieve durability while maintaining microsecond read latency?
  • 4What is the write latency trade-off in MemoryDB compared to ElastiCache?
  • 5Describe a use case where MemoryDB replaces both ElastiCache and RDS in an architecture.
  • 6What Redis features are not available in MemoryDB?
  • 7How does MemoryDB handle failover? What is the RTO?
  • 8How does ACL-based authentication work in MemoryDB?