ElastiCache

## What ElastiCache is, and what the engine choice actually decides ElastiCache is a managed in-memory cache that runs inside your VPC. AWS provisions the nodes, patches the engine, monitors them, replaces failed ones, and — for some engines — fails over automatically. What you still choose is the **engine**, and that choice decides which of those managed behaviours are even available to you. Today ElastiCache offers Valkey, Redis OSS and Memcached. The interview version of this question is rarely about which engine is faster. It is about whether you know that one engine has an availability story and the other does not. ## Memcached on ElastiCache A Memcached cluster is a set of independent nodes that know nothing about each other. Concretely: - **No replication and no failover.** There are no replicas, so there is nothing to promote. When a node fails, ElastiCache replaces it with an empty one and that node's share of the cache is gone. - **No backup and restore.** There is no snapshot of a Memcached cluster to export or restore from. - **Values are opaque.** Memcached stores byte strings keyed by a name. There are no server-side collections, no pub/sub, no server-side scripting. - **Multi-threaded.** A Memcached node serves commands on several threads, so a large multi-core node type is used efficiently by a single node. - **Sharding lives in the client.** ElastiCache publishes a *configuration endpoint*, and a client that supports **Auto Discovery** uses it to learn the current node list; the client then hashes each key to a node itself. Adding or removing a node redistributes some keys and those entries are simply missed until they are re-populated. ## Valkey and Redis OSS on ElastiCache These engines are deployed as a **replication group**: one primary per shard plus read replicas. That single structural difference is what unlocks the managed features: - **Multi-AZ with automatic failover** — put a replica in another Availability Zone and ElastiCache promotes it when the primary fails, keeping the cached data. - **Backup and restore** — scheduled or manual snapshots, restorable into a new cluster and exportable to S3. - **Read scaling** — replicas serve reads through a reader endpoint. - **Horizontal write scaling** — cluster mode splits the keyspace across shards. - **Security controls** — encryption in transit, an AUTH token, and user-level RBAC. - **A rich command set** — server-side collections, pub/sub, streams and scripting, so the cache can hold more than opaque blobs. The cost is that command execution on one shard is effectively single-threaded, so a single node's throughput ceiling is one core's worth of work; you add capacity by adding shards or replicas rather than by buying more cores in one box. ## Valkey versus Redis OSS Valkey is the community fork of Redis OSS created under the Linux Foundation after Redis changed its licence. On ElastiCache it is protocol-compatible — existing clients and commands work — and AWS prices it below Redis OSS for equivalent capacity. For a new cluster, Valkey is the usual default unless a specific client, module or engine version pins you to Redis OSS. It is not an AWS-proprietary engine, which is a common misconception worth correcting out loud. ## When Memcached is genuinely the right answer Say Memcached when all of these hold: 1. The cached data is regenerable from the source of truth and losing a slice of it is a cost blip, not an incident. 2. Values are opaque strings you serialize yourself, with no need for server-side structures. 3. You want maximum throughput per node on a memory-bound, CPU-light workload and want the node's cores used. 4. Nothing needs failover, backups, or per-user authentication of the cache tier. A session store, a rate-limiter, a leaderboard, a queue, or any cache whose loss would stampede the database into an outage all point the other way. ## The failure mode candidates miss The most common wrong answer is "Memcached is faster, so use it for caching." The throughput difference is real but rarely the constraint; the availability difference is what shows up at 3 a.m. If a node loss means the database suddenly absorbs that node's whole read share, you wanted an engine that can promote a replica with the data still in it.