Redis vs Memcached: Choosing the Right Engine

Amazon ElastiCache is a fully managed, in-memory caching service that makes it easy to deploy, manage, and scale popular open-source in-memory data stores in the cloud. It supports two engines: Redis and Memcached. By serving frequently requested data from memory rather than from a database, ElastiCache can reduce database load by orders of magnitude and cut response latency from milliseconds to microseconds. Choosing between Redis and Memcached is a common SAA-C03 exam question.

Memcached is a distributed, in-memory key-value store focused on simplicity and horizontal scalability. Key characteristics: multi-threaded (can use all CPU cores on a single node), simple key-value storage (strings only, no complex data structures), no persistence (data is lost when a node restarts), no replication (no standby or replicas), and horizontal sharding via client-side consistent hashing. Memcached is the right choice when you need a simple, large-scale cache and have no need for persistence, complex data types, or high availability.

Redis (Remote Dictionary Server) is a single-threaded (per-instance), feature-rich in-memory data structure store that supports strings, hashes, lists, sets, sorted sets, bitmaps, HyperLogLogs, streams, and geospatial indexes. Key advantages over Memcached: optional persistence (AOF and RDB snapshots), replication (read replicas and automatic failover), pub/sub messaging, Lua scripting, transactions (MULTI/EXEC), and cluster mode for horizontal sharding. Redis is the right choice for most real-world caching scenarios.

Redis supports two persistence mechanisms: RDB (Redis Database) — periodic point-in-time snapshots saved to disk at configurable intervals (fast restarts, but can lose data between snapshots). AOF (Append-Only File) — logs every write operation; on restart Redis replays the log to rebuild state (durability at the cost of larger files and slower restarts). In ElastiCache, you can enable AOF to persist data across node restarts. This is critical when ElastiCache is used not just as a cache but as a primary data store (for session data, for example).

Redis supports replication groups with one primary node that handles all writes and up to 5 read replicas that handle reads. With Multi-AZ and automatic failover enabled, ElastiCache promotes a read replica to primary automatically when the primary fails — typically completing the failover in under 60 seconds. This gives Redis-backed applications high availability that Memcached cannot match (Memcached has no replication). For production applications requiring HA caching, always use Redis with automatic failover.

Sorted sets are one of Redis's most powerful data structures. Each member has an associated floating-point score, and members are always kept in sorted order. This makes sorted sets ideal for leaderboards (rank by score), priority queues (process highest-priority jobs first), and rate limiting (sliding window with timestamps as scores). The operations ZADD, ZRANGE, ZREVRANGE, ZRANK, and ZRANGEBYSCORE are all O(log n) — extremely efficient even for millions of entries.

Redis pub/sub allows publishers to broadcast messages to channels without knowing who is subscribed. Subscribers receive all messages published to channels they subscribe to, in real time. Pub/sub messages are not persisted — if a subscriber is offline, it misses the message. For persistent messaging with guaranteed delivery, use Redis Streams (a more robust data structure added in Redis 5) or a purpose-built messaging service like SQS or SNS. For the SAA-C03 exam, Redis pub/sub is an option for lightweight real-time notifications between services.

Use this framework to choose for the SAA-C03 exam: Choose Memcached when you need: simple cache with no HA requirement, multi-threaded performance, horizontal scaling by adding nodes (pure cache). Choose Redis when you need: persistence (session store), replication and failover (HA), complex data types (sorted sets for leaderboards, sets, lists), pub/sub, Lua transactions, Cluster Mode for multi-shard horizontal scaling. If the exam question mentions any feature beyond simple key-value caching, Redis is almost always the answer.

ElastiCache offers several node type families: r7g (Graviton 3, memory-optimised — best price/performance, recommended for most caching), m7g (balanced compute and memory), and t4g (burstable, low cost for dev/test). Node sizes range from cache.t4g.micro (500 MB) to cache.r7g.16xlarge (425 GB). For production, choose a node size that keeps your dataset in memory with 20-25% headroom. Running out of memory causes evictions (Memcached) or OOM errors (Redis).

ElastiCache is deployed inside your VPC with security groups controlling access — no public internet access by default. For Redis, enable AUTH tokens (a password that clients must provide) and in-transit encryption (TLS) for connections, plus at-rest encryption using KMS. For Memcached, only in-transit TLS is available (no at-rest encryption or AUTH). When migrating from unencrypted to encrypted Redis, there is no in-place migration — you must create a new encrypted cluster and warm it up.

When a Redis or Memcached cache is full, the eviction policy determines which keys are removed to make space. Common Redis eviction policies: noeviction (returns OOM error — good when cache is primary store), allkeys-lru (evict least recently used across all keys — good general cache), volatile-lru (LRU among keys with TTL set — preserves non-expiring keys), allkeys-random (random eviction), allkeys-lfu (least frequently used). For typical caching use cases, allkeys-lru or allkeys-lfu are recommended.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Memcached is simple, multi-threaded, and has no HA — best for pure horizontal scaling of simple caches, Redis supports complex data structures, persistence, pub/sub, and Multi-AZ failover — best for most production caching scenarios, and sorted sets make Redis the natural choice for leaderboards and priority queues. Next up we explore Redis Replication Groups and Cluster Mode for horizontal sharding.