Amazon ElastiCache: Redis vs Memcached

Amazon ElastiCache is a fully managed, in-memory caching service that provides a high-performance, low-latency data store for applications. It supports two open-source caching engines: Redis and Memcached. ElastiCache abstracts away the operational overhead of deploying, patching, and monitoring cache clusters, allowing you to focus on application logic.

The primary purpose of ElastiCache is to reduce latency and improve throughput by storing frequently accessed data in memory, thereby offloading the backend database (e.g., Amazon RDS, DynamoDB). Common use cases include: - Database query result caching: Store the results of expensive SQL queries to avoid repeated database hits. - Session management: Store user session data (e.g., shopping cart contents) in a centralized cache across multiple application instances. - Real-time analytics: Use Redis’s sorted sets for leaderboards or stream processing. - API rate limiting: Use Redis’s atomic increment operations to track request counts.

#### Data Structures - Redis: Supports a wide variety of data structures: strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, geospatial indexes, and streams. This allows complex operations like intersection, union, and range queries directly on the server. - Memcached: Only supports simple key-value pairs where values are limited to strings up to 1 MB in size. No support for collections or complex data types.

#### Persistence - Redis: Offers optional persistence via snapshotting (RDB) or append-only file (AOF). RDB creates point-in-time snapshots at configurable intervals (e.g., every 5 minutes if at least 100 keys changed). AOF logs every write operation and can be configured for fsync every second or every write. This makes Redis suitable for use as a primary database (though ElastiCache for Redis is not recommended as a primary database for production; use RDS or DynamoDB instead). - Memcached: No persistence. Data is purely in-memory and lost on node failure or restart.

#### Replication and High Availability - Redis: Supports replication with a primary (master) node and up to 5 read replicas. ElastiCache for Redis also supports Multi-AZ with automatic failover, which promotes a read replica to primary if the primary fails. Redis Cluster mode enables automatic sharding across up to 500 shards (with 1 primary and up to 5 replicas per shard) for horizontal scaling. - Memcached: No replication. Data is sharded across nodes using consistent hashing (client-side or via auto-discovery). If a node fails, the data on that node is lost and must be reloaded from the source.

#### Multi-Threading - Redis: Single-threaded for command execution. This means Redis can handle a high volume of simple operations but may become CPU-bound for complex operations or large payloads. However, I/O threads and background tasks (like persistence) are handled by separate threads. - Memcached: Multi-threaded. It can utilize multiple CPU cores, making it better suited for workloads with large numbers of small objects and high throughput requirements.

#### Memory Management - Redis: Allows fine-grained memory management with configurable eviction policies: noeviction, allkeys-lru, allkeys-lfu, volatile-lru, volatile-lfu, allkeys-random, volatile-random, volatile-ttl. Redis also supports memory overcommitment and can use virtual memory (though not recommended). - Memcached: Uses a slab allocator to manage memory. Memory is divided into slabs of varying sizes (e.g., 64 bytes, 128 bytes, etc.). Items are stored in the smallest slab that fits their size. Memcached has a simpler eviction policy: LRU (least recently used) per slab class.

#### Scalability - Redis: Can scale vertically (larger node sizes) and horizontally using Redis Cluster (sharding). ElastiCache for Redis supports partitioning data across up to 500 shards, each with its own primary and replicas. - Memcached: Scales horizontally by adding nodes to a cluster. Data is distributed using consistent hashing. ElastiCache for Memcached supports up to 20 nodes per cluster (soft limit, can be increased).

#### Security - Both engines support encryption at rest (using KMS) and in transit (TLS). Redis also supports Redis AUTH (password) and Role-Based Access Control (RBAC) with multiple users and permissions. Memcached supports SASL-based authentication (though not enabled by default).

#### Redis Defaults (ElastiCache for Redis) - Default eviction policy: volatile-lru (evict least recently used keys among those with an expiration set). - Default port: 6379. - Maxmemory-policy: Configurable; can be changed to allkeys-lru for general LRU. - Snapshotting (RDB): Disabled by default in ElastiCache; you can enable it via parameter group. - AOF: Disabled by default. If enabled, you can set appendfsync to always, everysec, or no. - Replication: Up to 5 read replicas per primary. - Cluster mode: Disabled by default; can be enabled for sharding.

#### Memcached Defaults (ElastiCache for Memcached) - Port: 11211. - Max item size: 1 MB. - Memory: Allocates all available memory (minus overhead) to the cache. - Eviction policy: LRU per slab class. - Number of nodes: Up to 20 in a cluster. - Auto-discovery: Enabled by default; clients automatically discover all nodes.

The SAA-C03 exam will test your ability to select the appropriate engine based on requirements. Use the following decision criteria: - Need for complex data structures? Choose Redis (hashes, lists, sets, sorted sets, etc.). - Need persistence? Choose Redis. - Need high availability with automatic failover? Choose Redis with Multi-AZ. - Need to scale reads? Choose Redis with read replicas. - Need to cache simple key-value pairs with minimal overhead? Choose Memcached. - Need multi-threaded performance for many small objects? Choose Memcached. - Cost-sensitive and can tolerate data loss? Memcached is generally cheaper per GB of memory.

ElastiCache often works alongside: - Amazon RDS: Cache database query results to reduce load. - Amazon DynamoDB: Use DynamoDB Accelerator (DAX) for microsecond latency, but ElastiCache can also cache DynamoDB responses. - AWS Lambda: Store session state or temporary data between invocations (though DynamoDB is more common for Lambda). - Amazon CloudFront: For caching static content at the edge, not a direct alternative.

Both engines provide CloudWatch metrics: - CacheHits / CacheMisses: Ratio indicates effectiveness. - CurrConnections: Number of client connections. - Evictions: Number of keys evicted due to memory pressure. - CPUUtilization: For Redis, high CPU may indicate need for larger instance or sharding. - SwapUsage: High swap indicates memory pressure.

#### Redis CLI examples:

# Connect to ElastiCache Redis endpoint
redis-cli -h mycache.xxxxxx.ng.0001.use1.cache.amazonaws.com -p 6379

# Set a key
SET user:1001 '{"name":"Alice","age":30}'

# Get a key
GET user:1001

# Use a hash
HSET user:1001 name "Alice" age 30
HGETALL user:1001

# Check info
INFO

#### Memcached CLI examples (using telnet or netcat):

# Connect
telnet mycache.xxxxxx.cfg.use1.cache.amazonaws.com 11211

# Set a key
set user:1001 0 3600 32
{"name":"Alice","age":30}

# Get a key
get user:1001

# Stats
stats

A large e-commerce platform uses ElastiCache for Redis to store user session data. The application runs across multiple EC2 instances behind an Application Load Balancer. Sessions are stored as Redis hashes with fields like cart_items, login_token, and preferences. Redis’s persistence (AOF) is enabled to avoid session loss during maintenance. Multi-AZ replication ensures that if the primary node fails, a replica is promoted with minimal downtime. The cluster uses Cluster Mode with 4 shards to handle millions of concurrent sessions. Without Redis, sessions would be lost on server failures, causing users to log in again and lose cart contents.

A financial analytics company caches expensive SQL query results in ElastiCache for Memcached. The dashboard runs complex aggregations on Amazon RDS for MySQL. Caching reduces database load by 80%. Memcached is chosen because the data is ephemeral (TTL of 5 minutes) and does not require persistence or complex data structures. The cluster has 10 nodes with consistent hashing to distribute keys. If a node fails, the data is reloaded from the database on the next request. The multi-threaded nature of Memcached handles high throughput of cache get/set operations from multiple dashboard servers. Misconfiguration would include setting TTL too long, resulting in stale data, or too short, reducing cache effectiveness.

A mobile game uses ElastiCache for Redis with sorted sets to maintain a global leaderboard. Player scores are updated using ZINCRBY commands. Redis’s sorted set operations allow efficient retrieval of top players (ZREVRANGE). The cluster uses Cluster Mode with 2 shards to scale. Persistence is disabled because leaderboard data can be rebuilt from game events. If Redis were not used, the leaderboard would require frequent database writes and reads, increasing latency. A common mistake is using Memcached for this use case, which lacks sorted set support, forcing application-side sorting and increasing complexity.