ElastiCache

What is ElastiCache?

Amazon ElastiCache runs managed Redis (now also the OSS fork Valkey) or Memcached — in-memory data stores that sit between your application and its database, serving hot data from RAM at microsecond latency instead of the milliseconds a disk-backed query costs. AWS handles provisioning, patching, failover, and replication; you get a cache endpoint. The performance delta is the point: caching a query that takes 20 ms turns it into a 0.2 ms lookup, and offloads the database so it survives traffic it otherwise couldn’t.

Redis vs Memcached — the standing choice

Memcached is the simpler tool: multi-threaded, pure key-value, horizontally sharded — excellent when you need a big, fast, dumb cache and nothing more. Redis is a data-structures server: sorted sets, hashes, streams, pub/sub, Lua scripting, persistence, and replication — which is why it’s the default choice, doubling as rate-limiter backend, leaderboard, session store, and queue, not just a cache. Most teams pick Redis for the optionality; Memcached wins where raw simple-cache throughput and multi-threaded scaling are all that matter.

The hard part is never the cache — it’s invalidation

“There are only two hard things in computer science: cache invalidation and naming things” is a caching joke because it’s a caching truth. The patterns each have failure modes: cache-aside (app reads cache, falls back to DB, populates — simple, but risks serving stale data until TTL) is the common default; write-through keeps cache fresh at write cost; TTLs bound staleness bluntly. The dangerous incidents are thundering herd (a popular key expires, thousands of requests stampede the database simultaneously — mitigated with jittered TTLs and lock-based repopulation) and cache stampede on cold start. And a cache is not a database: it can evict anything anytime under memory pressure, so never treat it as the source of truth.

What people get wrong

• Caching without an invalidation strategy — silently serving stale data is worse than a slow query.
• Treating Redis as durable and losing data on eviction or failover when it was the only copy.
• No thundering-herd protection: synchronized key expiry turns a cache miss into a database outage.

Primary source: Amazon ElastiCache documentation

ElastiCache’s Two Engine Options

Amazon ElastiCache offers a choice between two underlying caching engines with meaningfully different capabilities: Memcached, a simpler, purely in-memory key-value cache well suited to straightforward caching needs with easy horizontal scaling through simple sharding, and Redis, which supports richer data structures (lists, sets, sorted sets, hashes), persistence to disk, replication, and pub/sub messaging — capabilities that go well beyond simple caching into use cases like session storage, real-time leaderboards, and message queuing. Most new deployments choose Redis specifically for this broader feature set, reserving Memcached for cases where its simpler architecture and easier horizontal scaling model are a better fit for a purely cache-only workload without any need for Redis’s more advanced capabilities.