ElastiCache — Redis vs Memcached

ElastiCache is an AWS managed in-memory caching service that supports two engines: Redis and Memcached. On the exam, you'll be asked to choose the right engine based on scenario requirements like persistence, multi-AZ, data structures, pub/sub, and backup needs. Understanding the specific feature differences between the two is critical for architectural decisions.

Core Concepts

ElastiCache Service Overview

ElastiCache is a fully managed in-memory data store service that improves application performance by retrieving data from fast, managed, in-memory caches instead of slower disk-based databases. It supports two open-source caching engines: Redis and Memcached.

Key facts:

• Sub-millisecond latency for read and write operations
• Deployed within a VPC for network isolation
• Supports encryption at rest and in transit (Redis only for encryption at rest)
• Integrates with CloudWatch for monitoring metrics like CPU, memory, and cache hit/miss ratios
• Automatic failover and Multi-AZ available only with Redis
• Both engines scale horizontally, but Redis supports cluster mode for partitioning data

When to Use ElastiCache

• Scenario asks to reduce database load by caching frequently accessed data
• Application requires sub-millisecond response times
• Question mentions "session store," "leaderboard," "real-time analytics," or "message broker"
• Looking to offload read-heavy workloads from RDS or DynamoDB

Redis Engine Features

Redis is an advanced in-memory key-value store that supports complex data structures, persistence, replication, and high availability through Multi-AZ deployments with automatic failover.

Key facts:

• Supports data persistence with snapshots (RDB) and append-only file (AOF)
• Multi-AZ with automatic failover for high availability
• Supports replication with up to 5 read replicas per primary node
• Provides backup and restore capabilities
• Supports advanced data structures: strings, lists, sets, sorted sets, hashes, bitmaps, hyperloglogs, geospatial indexes
• Pub/Sub messaging for real-time messaging applications
• Sorted sets enable leaderboards and ranking use cases
• Encryption at rest and in transit supported
• Supports transactions with MULTI/EXEC commands
• Redis Cluster mode enables horizontal scaling by partitioning data across multiple shards
• Redis uses a single-threaded architecture per shard

When to Use Redis

• Scenario requires data persistence or backup/restore capabilities
• Question mentions high availability, Multi-AZ, or automatic failover
• Application needs complex data structures (lists, sets, sorted sets)
• Use case involves leaderboards, real-time analytics, or pub/sub messaging
• Encryption at rest is a compliance requirement
• Read replicas are needed to scale read operations

Memcached Engine Features

Memcached is a simple, high-performance, distributed memory object caching system designed for simplicity and horizontal scalability through multi-threaded architecture.

Key facts:

• Multi-threaded architecture allows better utilization of multi-core systems
• No persistence - data is lost on node failure or restart
• No replication or automatic failover
• No backup and restore functionality
• Only supports simple key-value pairs (strings)
• Scales horizontally by adding more nodes to the cluster
• Auto Discovery feature simplifies node management by automatically identifying cluster nodes
• Encryption in transit supported, but no encryption at rest
• Lower operational overhead and simpler architecture than Redis
• Ideal for simple caching workloads without durability requirements

When to Use Memcached

• Scenario requires the simplest caching solution with multi-threaded performance
• Question emphasizes horizontal scaling by adding nodes without complexity
• No need for data persistence, backups, or high availability features
• Use case involves only simple key-value caching (no complex data structures)
• Application can tolerate data loss on cache node failure

Redis vs Memcached Comparison

Redis Cluster Mode

Redis Cluster mode enables horizontal scaling by partitioning data across multiple shards (node groups), each with a primary node and optional replicas.

Key facts:

• Cluster mode disabled: single shard with one primary and up to 5 replicas
• Cluster mode enabled: multiple shards (up to 500 nodes per cluster), each shard has one primary and optional replicas
• Data is partitioned using hash slots (16,384 slots distributed across shards)
• Enables both read and write scaling
• Online resharding allows adding/removing shards without downtime
• Each shard can have 0-5 replicas for high availability

When to Use Redis Cluster Mode

• Application needs to scale beyond single-node memory capacity
• Workload requires both read and write scaling
• Data can be partitioned by key for distribution across shards
• Scenario mentions "large dataset," "horizontal scaling," or "partitioning"

Session Store Use Case

Both Redis and Memcached can serve as session stores for web applications, but Redis is preferred when session persistence or failover is required.

Key facts:

• Session data stored in ElastiCache removes dependency on sticky sessions at the load balancer
• Redis ensures sessions persist across node failures with Multi-AZ and replication
• Memcached offers faster multi-threaded performance but sessions are lost on node failure
• Common exam scenario: "store user sessions for a stateless web application"

When to Use for Session Store

• Choose Redis when session durability and high availability are required
• Choose Memcached when sessions can be recreated on loss and multi-threaded performance is prioritized
• Scenario emphasizes "stateless application" or "distribute sessions across instances"
• ElastiCache removes the need for database-backed session storage, reducing latency

Leaderboard and Real-Time Analytics Use Case

Redis sorted sets enable efficient leaderboard and ranking operations with sub-millisecond performance for adding, updating, and querying ranked data.

Key facts:

• Sorted sets maintain elements with associated scores, automatically sorted by score
• Operations like ZADD, ZRANGE, ZRANK provide O(log(N)) complexity for ranking queries
• Ideal for gaming leaderboards, real-time voting, trending topics
• Memcached cannot support this use case due to lack of sorted data structures

When to Use for Leaderboards

• Scenario mentions "leaderboard," "ranking," "top N items," or "scoring system"
• Application needs real-time updates to rankings with low latency
• Redis is the only ElastiCache engine supporting this use case
• Exam will test your recognition that sorted sets are required

Pub/Sub Messaging Use Case

Redis pub/sub enables real-time message broadcasting to multiple subscribers, useful for chat applications, notifications, and event-driven architectures.

Key facts:

• Publishers send messages to channels; subscribers receive messages from channels they subscribe to
• Messages are not persisted - delivered only to active subscribers at publish time
• Supports pattern matching for channel subscriptions
• Memcached does not support pub/sub messaging
• Use Amazon SNS or Amazon MQ for durable, enterprise messaging with guaranteed delivery

When to Use for Pub/Sub

• Scenario involves "real-time notifications," "chat application," or "event broadcasting"
• Messages do not need durability or guaranteed delivery
• Redis is the only ElastiCache option; compare with SNS/SQS for durable messaging
• Exam tests whether you recognize Redis pub/sub vs managed message services

Backup and Restore

Redis supports automated and manual snapshots for backup and restore, enabling disaster recovery and cloning environments.

Key facts:

• Snapshots capture the entire dataset at a point in time
• Automated backups can be scheduled daily with retention period up to 35 days
• Manual snapshots persist until explicitly deleted
• Snapshots stored in Amazon S3 (managed by AWS)
• Restore creates a new Redis cluster from a snapshot
• Memcached has no backup capability

When to Use Backup and Restore

• Scenario requires disaster recovery, compliance archiving, or environment cloning
• Question mentions "restore cache state" or "recover data after failure"
• Redis is required; Memcached cannot fulfill this requirement
• Exam tests understanding that persistence enables backup/restore

Scaling Strategies

Both engines support horizontal scaling, but the mechanisms and limitations differ significantly.

Redis scaling:

• Vertical scaling: Change node type (requires creating a new cluster or using online resizing in some configurations)
• Horizontal scaling (reads): Add read replicas (up to 5 per shard)
• Horizontal scaling (writes and storage): Enable cluster mode and add shards
• Online resharding allows adding/removing shards without downtime

Memcached scaling:

• Vertical scaling: Change node type (requires creating a new cluster)
• Horizontal scaling: Add or remove nodes from the cluster
• Auto Discovery feature helps applications automatically identify all cache nodes
• No replication means each node holds unique data (partitioned by client-side hashing)

When to Choose Scaling Strategy

• Choose Redis read replicas for read-heavy workloads without changing data partitioning
• Choose Redis cluster mode when dataset exceeds single-node capacity or write scaling is needed
• Choose Memcached horizontal scaling for simple partitioning without replication or failover
• Exam scenarios test whether you understand replica vs shard scaling

Security and Encryption

Both engines support encryption in transit, but only Redis supports encryption at rest.

Key facts:

• Encryption in transit: Both Redis and Memcached support TLS
• Encryption at rest: Redis only (not available for Memcached)
• Redis AUTH: Token-based authentication for Redis (password protection)
• IAM authentication: Supported for Redis (using Redis AUTH with IAM-generated tokens)
• Memcached supports SASL-based authentication
• Network isolation provided by VPC security groups and subnet placement

When to Choose Based on Security

• Scenario requires encryption at rest for compliance: choose Redis
• Encryption in transit required: both engines support TLS
• IAM-based access control: choose Redis with IAM authentication
• Exam tests recognition that encryption at rest is Redis-only

Commonly Tested Scenarios / Pitfalls

1. Scenario: An application requires a caching layer with automatic failover and Multi-AZ support to ensure high availability. Which ElastiCache engine should be used?

Correct Approach: Choose Redis because it supports Multi-AZ with automatic failover for high availability. Memcached does not provide failover or replication.

Check first: Does the scenario mention "high availability," "automatic failover," or "Multi-AZ"? These keywords directly indicate Redis.

Do NOT do first: Do not choose Memcached just because the scenario mentions "simple caching." High availability requirements always override simplicity.

Why other options are wrong: Memcached lacks replication and failover capabilities, making it unsuitable for HA requirements. DynamoDB DAX is for DynamoDB acceleration, not general caching. CloudFront is a CDN, not an in-memory cache.

2. Scenario: A gaming application needs to maintain a real-time leaderboard with frequent score updates and queries for top 100 players. Which ElastiCache engine is most appropriate?

Correct Approach: Choose Redis because sorted sets efficiently handle leaderboard operations with sub-millisecond performance.

Check first: Does the use case require complex data structures like sorted sets, lists, or ranking? This is a Redis-only feature.

Do NOT do first: Do not choose Memcached thinking horizontal scaling alone solves the problem. Memcached only supports simple key-value pairs and cannot efficiently implement leaderboards.

Why other options are wrong: Memcached lacks sorted data structures needed for ranking. RDS or DynamoDB could work but would be much slower than Redis sorted sets. Exam expects you to choose the optimal solution.

3. Scenario: A company wants to cache database query results and needs the simplest solution with the best multi-threaded performance. Data loss on node failure is acceptable. Which engine should be chosen?

Correct Approach: Choose Memcached because it offers multi-threaded architecture for better CPU utilization, and persistence is not required.

Check first: Does the scenario explicitly state that data loss is acceptable or that persistence is not required? This is the key indicator for Memcached.

Do NOT do first: Do not default to Redis just because it has more features. Memcached is simpler and more efficient for basic caching when persistence is not needed.

Why other options are wrong: Redis would add unnecessary complexity and cost when persistence and advanced features are not required. The scenario explicitly allows data loss, making Redis's persistence features irrelevant.

4. Scenario: An application requires encryption at rest for cached sensitive data to meet compliance requirements. Which ElastiCache engine must be used?

Correct Approach: Choose Redis because it is the only ElastiCache engine that supports encryption at rest.

Check first: Does the scenario mention "encryption at rest" or compliance requirements around data-at-rest security? This eliminates Memcached immediately.

Do NOT do first: Do not assume both engines support encryption at rest because both support encryption in transit. Only Redis supports encryption at rest.

Why other options are wrong: Memcached only supports encryption in transit, not at rest. Other caching solutions like CloudFront or DynamoDB DAX serve different purposes and don't meet the general caching requirement.

5. Scenario: A web application needs to store user sessions in a distributed cache. Sessions must survive cache node failures. Which solution is appropriate?

Correct Approach: Choose Redis with Multi-AZ and replication enabled to ensure session persistence and automatic failover on node failure.

Check first: Does the scenario require session persistence or survival across failures? This indicates a need for replication and persistence.

Do NOT do first: Do not choose Memcached for session storage if sessions must survive failures. Memcached does not replicate data, so sessions are lost on node failure.

Why other options are wrong: Memcached loses all data on node failure, violating the requirement. Storing sessions in RDS or DynamoDB would work but introduce higher latency compared to ElastiCache Redis.

Step-by-Step Procedures or Methods

Task: Selecting the correct ElastiCache engine based on scenario requirements

1. Identify if the scenario requires data persistence, backup/restore, or automatic failover. If yes, choose Redis.
2. Check if the use case involves complex data structures like sorted sets, lists, or pub/sub messaging. If yes, choose Redis.
3. Determine if encryption at rest is a compliance requirement. If yes, choose Redis (only Redis supports encryption at rest).
4. Assess if the scenario emphasizes simplicity, multi-threaded performance, and explicitly states that data loss is acceptable. If yes, choose Memcached.
5. If the scenario mentions horizontal scaling by adding nodes without needing replication, consider Memcached for simplicity.
6. If the scenario requires read scaling with replicas or write scaling with sharding, choose Redis with cluster mode.
7. For session store use cases, choose Redis if sessions must survive failures; choose Memcached if sessions can be recreated and multi-threaded performance is prioritized.
8. When in doubt, if any advanced feature (HA, persistence, complex data types, pub/sub) is mentioned, default to Redis.

Task: Configuring Redis for high availability

1. Enable Multi-AZ when creating the Redis cluster to allow automatic failover.
2. Configure at least one read replica per shard (up to 5 replicas supported).
3. Select automatic failover option to promote a replica to primary on failure.
4. Place primary and replica nodes in different Availability Zones.
5. Enable automated backups with appropriate retention period (1-35 days).
6. Use CloudWatch alarms to monitor ReplicationLag and CPUUtilization metrics.
7. Ensure security groups allow traffic between primary and replica nodes.

Practice Questions

Q1: A company is building a web application that requires storing user session data with sub-millisecond latency. The sessions must persist even if a cache node fails. Which ElastiCache configuration should be used?
(a) Memcached with multiple nodes for horizontal scaling
(b) Redis with Multi-AZ enabled and at least one read replica
(c) Redis Cluster mode enabled with no replicas
(d) Memcached with Auto Discovery enabled

Ans: (b)
Redis with Multi-AZ enabled and at least one read replica ensures session persistence and automatic failover on node failure. Option (a) Memcached loses all data on node failure. Option (c) Redis without replicas does not provide failover capability. Option (d) Memcached Auto Discovery helps with node identification but does not provide data persistence.

Q2: An online gaming platform needs to implement a leaderboard that updates player scores in real-time and retrieves the top 100 players with minimal latency. Which AWS service and feature should be used?
(a) DynamoDB with a Global Secondary Index sorted by score
(b) Redis ElastiCache with sorted sets
(c) Memcached ElastiCache with horizontal partitioning
(d) RDS MySQL with an indexed score column

Ans: (b)
Redis sorted sets are specifically designed for ranking and leaderboard use cases with O(log(N)) complexity for updates and queries, providing sub-millisecond performance. Option (a) DynamoDB GSI would work but with higher latency than Redis. Option (c) Memcached cannot implement sorted rankings with simple key-value pairs. Option (d) RDS would have much higher latency than in-memory Redis.

Q3: A compliance requirement mandates that all cached data must be encrypted at rest. The application also needs automatic failover for high availability. Which ElastiCache engine must be selected?
(a) Memcached with encryption in transit enabled
(b) Redis with encryption at rest and Multi-AZ enabled
(c) Either Redis or Memcached with appropriate encryption settings
(d) Memcached with SASL authentication

Ans: (b)
Only Redis supports encryption at rest, which is required by the compliance mandate. Multi-AZ provides the needed automatic failover. Option (a) Memcached does not support encryption at rest. Option (c) is incorrect because Memcached cannot meet the encryption at rest requirement. Option (d) SASL provides authentication, not encryption at rest.

Q4: An application requires a simple caching layer for database query results. The architecture must maximize throughput on multi-core instances. Data loss during cache node failures is acceptable as data can be reloaded from the database. Which ElastiCache engine is most appropriate?
(a) Redis with cluster mode enabled
(b) Redis with cluster mode disabled and read replicas
(c) Memcached with multiple nodes
(d) Redis with Multi-AZ enabled

Ans: (c)
Memcached's multi-threaded architecture maximizes throughput on multi-core instances. Since data loss is acceptable and no persistence is required, Memcached is simpler and more efficient than Redis. Options (a), (b), and (d) all involve Redis, which adds unnecessary complexity and cost when persistence and failover are not required.

Q5: A solutions architect is designing a real-time chat application that needs to broadcast messages to all connected users. The messages do not need to be stored permanently. Which ElastiCache feature should be used?
(a) Memcached with client-side message distribution
(b) Redis pub/sub messaging
(c) Redis sorted sets
(d) Memcached with consistent hashing

Ans: (b)
Redis pub/sub is designed for real-time message broadcasting to multiple subscribers without persistence. Option (a) Memcached does not support pub/sub messaging natively. Option (c) Sorted sets are for ranking, not messaging. Option (d) Consistent hashing is for data distribution, not message broadcasting.

Q6: A company needs to scale its ElastiCache cluster to handle increased read traffic. The dataset must remain consistent across all nodes, and automatic failover is required. What is the correct approach?
(a) Use Memcached and add more nodes to the cluster
(b) Use Redis with cluster mode disabled and add read replicas
(c) Use Redis with cluster mode enabled and add more shards
(d) Use Memcached with Auto Discovery enabled

Ans: (b)
Redis with cluster mode disabled and read replicas provides read scaling while maintaining data consistency through replication, plus automatic failover with Multi-AZ. Option (a) Memcached does not replicate data or provide failover. Option (c) Adding shards partitions data, which is for scaling storage and writes, not just read scaling. Option (d) Memcached does not meet the failover requirement.

Quick Review

• Redis: Use when you need persistence, Multi-AZ/automatic failover, backup/restore, replication, complex data structures, pub/sub, encryption at rest, or sorted sets for leaderboards.
• Memcached: Use when you need the simplest solution with multi-threaded performance, horizontal scaling, and data loss is acceptable (no persistence required).
• Encryption at rest is supported by Redis only; both engines support encryption in transit.
• Multi-AZ with automatic failover is Redis only; Memcached has no replication or failover.
• Sorted sets in Redis enable efficient leaderboard and ranking implementations.
• Redis pub/sub supports real-time messaging without persistence; Memcached does not support pub/sub.
• Session store: Choose Redis if sessions must survive failures; choose Memcached if sessions can be recreated and multi-threaded performance is key.
• Redis cluster mode enables horizontal scaling through sharding for both reads and writes; cluster mode disabled supports up to 5 read replicas per shard.
• Memcached multi-threaded architecture better utilizes multi-core CPUs; Redis is single-threaded per shard.
• Backup and restore capabilities exist only in Redis, with snapshots stored in S3 and retention up to 35 days.