Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon ElastiCache is a fully managed in-memory data store based on Redis or Memcached. It is commonly placed in front of services such as Amazon RDS or DynamoDB to reduce database load and provide faster, lower-latency reads.
For the exam, the most important decision is choosing between Redis and Memcached based on persistence, data structures, high availability, backup, partitioning, and scaling requirements.
Key Concepts
ElastiCache fundamentals
- ElastiCache is a key-value store that keeps data in memory.
- It provides very low latency and high throughput compared with retrieving the same data from a traditional database.
- ElastiCache nodes run on Amazon EC2 instances, so the selected node type determines available memory and compute capacity.
- It can cache data from databases such as Amazon RDS and Amazon DynamoDB.
- It is most effective when data is frequently accessed, relatively static, expensive to retrieve, or slow to calculate.
A common caching flow is:
- The application writes authoritative data to the backend database.
- The application loads or updates the corresponding cache entry.
- A later read checks ElastiCache first.
- A cache hit returns the value quickly without querying the backend database.
- A cache miss requires retrieving the value from the backend and usually populating the cache.
The application or caching design must account for possible synchronization delays. Cached data may be stale, so caching is appropriate only when the application can tolerate that behavior or has an invalidation/update strategy.
Redis and Memcached comparison
| Capability | Memcached | Redis cluster mode disabled | Redis cluster mode enabled |
|---|---|---|---|
| Data model | Simple data types | More complex data types | More complex data types |
| Persistence | No | Yes | Yes |
| Backup and restore | No backup capability | Automated backups and manual snapshots | Automated backups and manual snapshots |
| Replication and high availability | No replication or automatic failover | Replicas and automatic failover | Replicas and automatic failover per shard |
| Partitioning | Nodes are separate partitions | Single primary with replicas; no data partitioning across shards | Data partitioned across shards |
| Scaling out | Add nodes; each node is a separate partition | Add replicas for read capacity | Add shards for data and capacity distribution |
| Scaling up | Change the node type | Change the node type | Change the node type |
| Multithreading | Yes | No | No |
| Encryption options in the lesson’s comparison | Not available | Available | Available |
The exact capabilities available can depend on engine version and configuration. For exam questions based on this comparison, focus on the architectural distinctions: Memcached is simpler and distributed across independent nodes, while Redis provides persistence, richer data structures, replication, failover, and backups.
Redis cluster mode disabled versus enabled
Redis cluster mode disabled uses a single primary data set with replicas. It is appropriate when the data set fits within one primary node and the main requirement is read scaling or high availability.
Redis cluster mode enabled distributes data across multiple shards. Each shard has a primary and may have replicas. This is the option to consider when the data set or write workload requires horizontal partitioning across shards.
Common use cases
ElastiCache is commonly used for:
- Database caching in front of RDS or DynamoDB
- Web session state storage
- Frequently accessed, relatively static data
- Leaderboards
- Streaming data dashboards
- Reducing the cost or latency of repeated database operations
For session state, both ElastiCache and DynamoDB may be viable. The correct choice depends on whether the scenario emphasizes in-memory performance and cache behavior or durable, persistent storage.
Exam-Relevant Takeaways
- Choose ElastiCache when the requirement is very low-latency access to frequently used data.
- Treat the backend database as the source of truth unless the architecture explicitly assigns another role to the cache.
- The application must tolerate stale data or implement suitable cache invalidation and refresh behavior.
- Choose Memcached for a simple, nonpersistent cache that can scale by adding independent nodes.
- Choose Redis when you need persistence, backups, snapshots, replication, automatic failover, richer data types, or more advanced caching behavior.
- Choose Redis cluster mode disabled when a single data set fits on one primary and replicas are sufficient for read scaling and availability.
- Choose Redis cluster mode enabled when data must be partitioned across shards or the workload requires horizontal scaling beyond one primary.
- Memcached is multi-threaded; Redis is not. This can be a deciding clue in performance-oriented questions.
- Multi-AZ placement alone does not provide high availability for Memcached because its nodes are not replicated and do not automatically fail over.
- Redis read replicas and failover operate on a per-shard basis when cluster mode is enabled.
Architecture Decision Guide
| Requirement | Recommended choice | Reason |
|---|---|---|
| Simple volatile cache with independent nodes | Memcached | Nonpersistent key-value caching with scale-out by adding nodes |
| Persistent in-memory data store | Redis | Supports persistence, snapshots, and automated backups |
| Automatic failover and replicas | Redis | Provides replication and high availability features |
| Richer data structures | Redis | Better suited to more complex data models |
| Multi-threaded cache engine | Memcached | Memcached is multi-threaded, unlike Redis |
| One data set with read replicas | Redis cluster mode disabled | Replicas improve read capacity and availability without sharding the data |
| Data partitioned across multiple shards | Redis cluster mode enabled | Supports horizontal distribution of the data set |
| Frequently accessed data that may be stale | ElastiCache | Reduces backend reads and latency when stale data is acceptable |
| Durable authoritative application data | RDS, DynamoDB, or another durable database | ElastiCache should not replace the durable source of truth by default |
Common Exam Traps
- Confusing caching with persistence: Memcached data is not persistent. A cache restart or node loss can remove the data.
- Assuming Multi-AZ means replication: Memcached nodes can be distributed across Availability Zones, but they do not replicate data or automatically fail over.
- Selecting Redis cluster mode disabled for sharding: Cluster mode disabled uses one primary data set with replicas. Use cluster mode enabled when data must be distributed across shards.
- Assuming every cache read is current: Cache synchronization can lag behind the backend database. The application must tolerate or manage staleness.
- Choosing Memcached when backups are required: Memcached does not provide the Redis backup and snapshot capabilities described here.
- Choosing Redis for a simple, disposable cache without considering complexity: If persistence, replicas, failover, and richer data types are unnecessary, Memcached may be the more direct fit.
- Confusing scale-up and scale-out: Changing the node type is vertical scaling. Adding Memcached nodes, Redis replicas, or Redis shards are different horizontal scaling approaches.
- Assuming Redis always partitions data: Redis cluster mode enabled partitions data across shards; cluster mode disabled does not distribute one data set across multiple shards.
Real-World Engineer Notes
- Define the cache consistency model explicitly. Decide whether the application uses cache-aside behavior, write-through updates, expiration, or explicit invalidation.
- Cache only data that can be reconstructed or refreshed from the authoritative backend unless Redis persistence is part of the intended design.
- Monitor cache hit rate, evictions, memory usage, latency, and backend database load. A cache with a poor hit rate may add operational complexity without reducing database work.
- Consider failure behavior. The application should continue to behave correctly after cache entries expire, nodes fail, or the cache is temporarily unavailable.
- Use TTLs and invalidation carefully. Long TTLs improve hit rates but increase the risk of stale values; short TTLs improve freshness but increase backend traffic.
- Select the engine based on workload and data semantics, not simply on the fact that both are called caches.
Quick Reference Summary
- ElastiCache: Managed in-memory key-value caching with very low latency.
- Memcached: Simple, volatile, multi-threaded, horizontally scalable through independent nodes; no replication or backup.
- Redis: Supports persistence, richer data types, replicas, failover, backups, and snapshots.
- Redis cluster mode disabled: One primary data set with replicas; no sharding of that data set.
- Redis cluster mode enabled: Data distributed across shards; replicas and failover are managed per shard.
- Best cache candidates: Frequently accessed, relatively static, costly, or slow-to-retrieve data.
- Important limitation: Applications must handle cache misses and potentially stale data.
Flashcards
- Q: What type of database is Amazon ElastiCache?
A: A managed in-memory key-value data store based on Redis or Memcached.
- Q: Why place ElastiCache in front of RDS or DynamoDB?
A: To reduce backend database load and return frequently accessed data with lower latency.
- Q: Which ElastiCache engine is nonpersistent?
A: Memcached.
- Q: Which engine supports automated backups and manual snapshots?
A: Redis.
- Q: Which engine supports replication and automatic failover?
A: Redis.
- Q: What happens when Memcached nodes are added?
A: Capacity scales out through additional independent nodes, with data distributed among separate partitions.
- Q: What is the main difference between Redis cluster mode enabled and disabled?
A: Cluster mode enabled partitions data across shards; cluster mode disabled keeps one data set on a primary with replicas.
- Q: Which engine is multi-threaded?
A: Memcached.
- Q: What is a cache hit?
A: A requested value is found in ElastiCache and returned without querying the backend database.
- Q: What type of data is a good caching candidate?
A: Frequently accessed data that is expensive or slow to retrieve and can tolerate some staleness.
- Q: Why can Multi-AZ Memcached placement be misleading?
A: Nodes may be spread across Availability Zones, but Memcached does not replicate data or automatically fail over.
- Q: Which ElastiCache engine is commonly considered for session state?
A: Redis or Memcached, depending on persistence and availability requirements; DynamoDB may also be appropriate.
Practice Questions
Question 1
A company wants to cache product catalog data retrieved from Amazon RDS. The data is frequently read, can be regenerated from RDS, and does not require persistence, replication, backups, or complex data types. The company wants to scale the cache by adding independent nodes.
Which solution best fits these requirements?
- A. ElastiCache for Redis with cluster mode disabled
- B. ElastiCache for Redis with cluster mode enabled
- C. ElastiCache for Memcached
- D. Amazon DynamoDB with point-in-time recovery
Correct answer: C. ElastiCache for Memcached
Explanation: Memcached is designed for simple, volatile caching and scales out by adding independent nodes. Redis features are unnecessary when persistence, replication, backups, and richer data types are not required.
Question 2
An application requires an in-memory data store that supports automated backups, manual snapshots, replication, and automatic failover. The data uses complex data structures.
Which option should the solutions architect recommend?
- A. Memcached distributed across multiple Availability Zones
- B. Redis
- C. Amazon S3 only
- D. An additional RDS read replica without caching
Correct answer: B. Redis
Explanation: Redis supports persistence, backups, snapshots, complex data types, replication, and automatic failover. Memcached does not provide these capabilities.
Question 3
A Redis deployment must distribute a data set across multiple shards because it no longer fits on a single primary node. Which configuration should be selected?
- A. Redis cluster mode disabled
- B. Redis cluster mode enabled
- C. Memcached with one node
- D. An RDS Multi-AZ standby
Correct answer: B. Redis cluster mode enabled
Explanation: Redis cluster mode enabled partitions the data across shards, allowing horizontal distribution of the data set. Cluster mode disabled uses a single primary data set with replicas.
Question 4
A web application stores user sessions in ElastiCache. During a cache outage, users must not lose important durable application data, and the session data can be recreated or recovered from the application’s backend system.
Which design principle is most important?
- A. Treat the cache as the only system of record
- B. Ensure the application can handle cache misses and repopulate sessions
- C. Disable expiration for all cache entries
- D. Use Memcached and assume Multi-AZ placement provides replication
Correct answer: B. Ensure the application can handle cache misses and repopulate sessions
Explanation: Cached data may be lost, expire, or become unavailable. The application should use a durable backend where necessary and handle cache misses safely. Multi-AZ placement does not create Memcached replication or automatic failover.
Question 5
An architect is comparing two caching engines. The workload benefits from a multi-threaded engine, uses simple key-value data, and does not require persistence or backups. Which additional fact supports selecting Memcached?
- A. The workload requires automatic failover between replicas
- B. The workload requires snapshots for disaster recovery
- C. The workload can scale by adding independent cache nodes
- D. The workload requires data partitioning across Redis shards
Correct answer: C. The workload can scale by adding independent cache nodes
Explanation: Memcached is multi-threaded, supports simple data types, and scales out through independent nodes. The other options describe Redis capabilities or Redis-specific sharding.