Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon ElastiCache scaling depends on whether the deployment uses Memcached or Redis and, for Redis, whether cluster mode is enabled. The key exam distinction is how each engine handles partitions, replicas, resharding, vertical scaling, and data loss.
Key Concepts
Horizontal and Vertical Scaling
- Horizontal scaling adds capacity by adding nodes or shards.
- Vertical scaling changes the instance type to provide more CPU, memory, or network capacity.
- ElastiCache nodes run on AWS-managed infrastructure based on Amazon EC2, but you manage scaling through ElastiCache configuration rather than directly modifying an EC2 instance.
The operational behavior differs by engine and cluster configuration. Some changes are performed online, while others require creating a replacement cluster or performing an offline operation.
Memcached Scaling
Memcached uses a cluster of independent nodes. Data is distributed across nodes, but nodes do not replicate one another.
Memcached scaling options include:
- Horizontal scaling: Add nodes to the cluster.
- Vertical scaling: Change the node type by creating a new cluster with the desired instance type.
Important characteristics:
- Each node contains a partition of the cached data.
- A node failure can make the data stored on that node unavailable.
- Memcached does not provide replica nodes for high availability.
- Memcached does not provide a durable backup of cached data.
- The application or another data source must be able to repopulate lost entries.
Before choosing Memcached, assess the cost and operational impact of rebuilding the cache. Consider the source of the data, database load, network transfer, rebuild duration, and user-facing consequences.
Redis Cluster Mode Disabled
With Redis cluster mode disabled, the deployment has a single shard consisting of:
- One primary node
- Zero or more replica nodes
Replicas can improve availability and provide read capacity, but they do not create additional shards. Therefore, this configuration does not horizontally partition the dataset across multiple shards.
Scaling options include:
- Add a replica.
- Change the node type.
- ElastiCache creates a new cluster and migrates the data as part of the scaling operation.
This model is suitable when the dataset fits within one shard but additional replicas are needed for availability or read scaling.
Redis Cluster Mode Enabled
With cluster mode enabled, Redis uses multiple shards. Each shard contains:
- One primary node
- Zero to five replica nodes
The primary handles writes for the shard, while replicas provide redundancy and can support reads. Multiple shards allow the dataset and workload to be partitioned horizontally.
Scaling options include:
- Add or remove shards through resharding.
- Change the node type for vertical scaling.
- Perform online resharding when supported by the operation and configuration.
- Perform offline resharding for changes that require downtime or a more flexible maintenance operation.
- Upgrade the engine through an offline operation when required.
The exact availability and supported workflow depend on the specific ElastiCache engine version and configuration, so production changes should be validated against current AWS documentation.
Shards, Replicas, and Availability Zones
A shard is a partition of the dataset. A replica is a copy of a shard’s primary data.
These concepts solve different problems:
- Adding shards increases partitioned capacity and can distribute workload.
- Adding replicas improves redundancy and can provide additional read capacity.
- Placing nodes across Availability Zones improves resilience to an Availability Zone failure.
- Replicas do not turn a single-shard Redis deployment into a multi-shard deployment.
For Memcached, placing nodes across Availability Zones can distribute the cluster infrastructure, but it does not provide replicated copies of the data.
Exam-Relevant Takeaways
- Memcached nodes are independent partitions, not replicas. Losing a node means losing the cached entries assigned to it.
- Memcached does not provide native data replication or durable backup for cache contents.
- Memcached horizontal scaling means adding nodes.
- Memcached vertical scaling requires creating a new cluster with a different node type.
- Redis cluster mode disabled has one shard with a primary and optional replicas.
- Redis cluster mode enabled supports multiple shards and horizontal partitioning.
- Redis replicas provide copies of shard data; shards distribute the dataset.
- In cluster mode enabled, resharding adds or removes shards.
- Online resharding is intended to minimize disruption; offline operations provide a broader maintenance path but may require downtime.
- A cache architecture must account for how data is rebuilt after node or cluster loss.
Architecture Decision Guide
| Requirement | Better fit or configuration | Reason |
|---|---|---|
| Simple distributed cache where data can be regenerated | Memcached | Supports adding nodes and distributes data across independent nodes |
| Cache data must have replicas | Redis | Redis supports primary-replica relationships |
| Dataset must be partitioned across multiple shards | Redis cluster mode enabled | Supports multiple shards and resharding |
| Dataset fits on one shard but read scaling or failover is needed | Redis cluster mode disabled | Supports a primary with replicas |
| Need to increase capacity without changing the number of partitions | Add Redis replicas or change node type, depending on the bottleneck | Replicas address redundancy/read capacity; node-type changes address per-node limits |
| Need to increase total partitioned capacity | Add Redis shards in cluster mode enabled | New shards distribute data and workload |
| Cache rebuild is expensive or causes unacceptable database load | Redis with appropriate replicas and failover design | Replicated cache data reduces dependence on full reconstruction |
| Cache entries are disposable and the application already handles misses | Memcached may be appropriate | Data loss is acceptable if entries can be regenerated |
Common Exam Traps
- Confusing a node with a replica: A Memcached node is generally a separate data partition, not a copy of another node.
- Assuming all ElastiCache engines scale identically: Memcached, Redis cluster mode disabled, and Redis cluster mode enabled have different scaling models.
- Assuming Redis replicas provide sharding: Replicas copy data; they do not increase the number of partitions.
- Assuming cluster mode disabled supports multiple shards: It uses a single shard, although that shard can have replicas.
- Ignoring cache repopulation: A cache is not automatically harmless to lose. Rebuilding it can overload the backing database or increase latency.
- Treating vertical scaling as an in-place EC2 resize: ElastiCache scaling workflows may create a replacement cluster or migrate data rather than modifying the existing node directly.
- Choosing Memcached for durable state: Cached data should be recoverable from a system of record. Memcached is not a durable database.
- Assuming Availability Zones imply replication: Multi-AZ placement improves infrastructure resilience, but replication behavior depends on the engine and topology.
Real-World Engineer Notes
When evaluating a cache design, identify the actual bottleneck before scaling:
- If individual nodes are running out of memory or CPU, consider vertical scaling.
- If the total dataset or aggregate throughput exceeds a single shard, consider Redis cluster mode enabled and additional shards.
- If reads are the bottleneck, replicas may help, but verify client-side read routing and consistency requirements.
- If failover is the primary concern, use replicas and distribute them across Availability Zones where supported.
- Measure cache miss rates and backend load before and after a scaling change.
- Plan for cache warming, invalidation, and recovery. A cache that takes hours to rebuild may require a different architecture even if the cache itself is technically disposable.
- Treat online operations as lower-disruption, not risk-free. Validate capacity, client compatibility, engine version, and failover behavior before production changes.
Quick Reference Summary
- Memcached: independent nodes, no replication, add nodes for horizontal scaling, new cluster for vertical scaling.
- Redis cluster mode disabled: one shard, one primary, optional replicas; no multi-shard partitioning.
- Redis cluster mode enabled: multiple shards, each with one primary and zero to five replicas; supports resharding.
- Shard: partitions data.
- Replica: copies a shard’s data.
- Availability Zones: improve placement resilience but do not automatically make Memcached data durable.
- Design question: Can the application efficiently recreate lost cache data, and what is the impact of doing so?
Flashcards
- Q: How does Memcached distribute data?
A: Across independent nodes. Nodes contain partitions of data rather than replicated copies.
- Q: What happens to Memcached data when a node is lost?
A: Entries assigned to that node are lost and must be recreated by the application or backing data source.
- Q: How is Memcached horizontally scaled?
A: By adding nodes to the cluster.
- Q: How is Memcached vertically scaled?
A: By creating a new cluster using a different node type.
- Q: How many shards exist in Redis cluster mode disabled?
A: One shard, with a primary and optional replicas.
- Q: What is the purpose of Redis replicas?
A: To provide copies of shard data for redundancy and potentially support read scaling.
- Q: What does Redis cluster mode enabled add?
A: Multiple shards, allowing horizontal partitioning of data and workload.
- Q: What is resharding?
A: Adding or removing shards and redistributing the dataset across the shard topology.
- Q: How many replicas can each Redis cluster-mode-enabled shard have according to this lesson?
A: Zero to five replicas.
- Q: Does adding Redis replicas create additional shards?
A: No. Replicas copy existing shard data; adding shards is what increases partitioning.
- Q: Why can losing a Memcached node affect the application even though the cache is non-durable?
A: Rebuilding entries can increase latency, database load, network traffic, and recovery time.
- Q: Which Redis scaling approach is designed to reduce disruption during shard changes?
A: Online resharding, when supported by the configuration and operation.
Practice Questions
Question 1
A company uses Memcached for product catalog caching. It needs more total cache capacity, and cache entries can be regenerated from an Amazon Aurora database. Which change is most appropriate?
A. Add read replicas to the Memcached cluster
B. Add nodes to the Memcached cluster
C. Enable Redis cluster mode disabled
D. Add replicas to each Memcached shard
Correct answer: B
Explanation: Memcached scales horizontally by adding independent nodes. Memcached does not use Redis-style primary-replica shards, so options A and D are invalid. Redis is a different engine and is not a configuration change within the existing Memcached cluster.
Question 2
An application uses Redis cluster mode disabled. The dataset fits in one shard, but read traffic is increasing and the company wants improved failover capability. What should the solutions architect recommend?
A. Add replicas to the Redis deployment
B. Add Memcached nodes
C. Add Redis shards while leaving cluster mode disabled
D. Remove the primary and use replicas only
Correct answer: A
Explanation: Redis cluster mode disabled supports one shard with a primary and optional replicas. Replicas can provide redundancy and additional read capacity. Multiple shards require cluster mode enabled.
Question 3
A Redis deployment uses cluster mode enabled. The dataset and request volume have grown beyond the capacity of the current shard layout. The team wants to increase partitioned capacity while minimizing application disruption. Which approach is most appropriate?
A. Add replicas only
B. Perform online resharding to add shards, if supported by the current configuration
C. Move the workload to Memcached because it has no shards
D. Disable all replicas before adding capacity
Correct answer: B
Explanation: Cluster mode enabled supports multiple shards and resharding. Adding shards increases partitioned capacity. Online resharding is the lower-disruption option when supported. Replicas improve redundancy and read capacity but do not increase the number of data partitions.
Question 4
A team proposes Memcached for session data. The sessions cannot be reconstructed if a cache node fails, and losing sessions would log users out. What is the primary architectural concern?
A. Memcached cannot add nodes
B. Memcached does not replicate data between nodes
C. Memcached always requires offline resharding
D. Memcached supports too many replicas
Correct answer: B
Explanation: Memcached nodes contain independent data partitions and do not provide replica copies. If session state cannot be recreated, the team should use a design with appropriate replication or persist session state in a durable system of record.
Question 5
An engineer needs more memory per Redis node in a cluster-mode-enabled deployment. The engineer also wants to understand whether the operation can be performed online or offline. Which statement is correct?
A. Redis cannot change node types after creation
B. A node-type change is a form of vertical scaling, and the supported online or offline workflow depends on the Redis configuration and operation
C. Adding replicas always provides more memory to the primary node
D. Adding shards changes the memory size of existing nodes
Correct answer: B
Explanation: Changing the node type is vertical scaling. Adding replicas provides additional copies and potentially read capacity, but it does not increase the memory available on an existing primary. Adding shards changes the partition layout rather than resizing existing nodes.