beginnerintermediateadvanced

AWS · ElastiCache / Managed Caching

ElastiCache / Managed Caching

Redis/Valkey vs Memcached, cache-population strategies, stampede prevention, availability, and the system-of-record boundary

Memcached: simple, multithreaded, no failoverValkey/Redis OSS: structures, pub/sub, replication
Cache-aside vs write-throughfill on miss (can stale) vs fill on write (never stale)
SET NX PX lock — best-effort onlystops a stampede, does not guarantee mutual exclusion
Multi-AZ failover in secondssame endpoint, async replication can still lose data
Cache is never the system of recordalways safe to lose, unless durability is explicitly enabled

1.Redis vs Memcached Use Cases

ElastiCache runs three engines: Valkey, Redis OSS, and Memcached. Memcached is simpler and multithreaded, good for pure key-value object caching that must scale out across many nodes. Valkey and Redis OSS add data structures (sorted sets, hashes, lists), pub/sub, and replication with automatic failover, at the cost of being single-threaded per node.

Key features

Memcached is multithreaded per node; Valkey and Redis OSS are not — a large Memcached node can use multiple CPU cores for one cache, Redis/Valkey scales cores by adding nodes/shards instead
Memcached has no replication or automatic failover; Valkey/Redis OSS support both, so only Valkey/Redis OSS can survive a node failure without losing that node's data
Memcached supports only simple string/object values; Valkey/Redis OSS add sorted sets, hashes, lists, and other data structures used directly for leaderboards, counters, and recommendation data
Only Valkey/Redis OSS support pub/sub messaging (SUBSCRIBE/PUBLISH) — Memcached has no equivalent
Memcached data partitions client-side across nodes by default; Valkey/Redis OSS (cluster mode enabled) partitions data server-side across shards with online resharding
Engine choice is made at cluster creation and is not switchable in place — moving between engines means creating a new cluster and migrating data

Memcached vs Valkey/Redis OSS — deciding factors

Memcached vs Valkey/Redis OSS — deciding factors
Property	Memcached	Valkey / Redis OSS
Data types	Simple strings/objects only	Strings, sorted sets, hashes, lists, bitmaps, geospatial
Multithreaded per node	Yes	No
Replication / automatic failover	No	Yes
Pub/Sub	No	Yes
Data partitioning	Client-side, built in	Server-side in cluster mode, with online resharding

Memcached vs Valkey/Redis OSS

Memcached

Simple string/object values only
Multithreaded — scales cores within one node
No replication, no automatic failover
No pub/sub

Valkey / Redis OSS

Sorted sets, hashes, lists, geospatial data types
Single-threaded per node — scale by adding shards
Replication with automatic failover
Pub/sub messaging built in

Signature

Memcached (simple, multithreaded, no failover) vs Valkey/Redis OSS (data structures, pub/sub, failover)

Memcached: simple values, multithreaded, no replication/failover, no pub/sub — pick it for pure object caching that scales out. Valkey/Redis OSS: data structures, pub/sub, replication with automatic failover — pick it when the workload needs any of those.

2.Cache-Aside, Write-Through, TTL, and Invalidation

Cache-aside (lazy loading) reads the cache first, and on a miss queries the database and writes the result into the cache — only requested data is ever cached, but data can go stale until the next miss. Write-through updates the cache every time the database is updated, so the cache is never stale, but costs a write to the cache on every write and can leave the cache empty for data that was never read since a node was replaced. TTL puts a time limit on both, expiring keys so reads eventually re-fetch fresh data.

Key features

Cache-aside (lazy loading): read cache → on miss, read database → write result to cache — a cache miss costs three trips (cache, database, cache) instead of one
Cache-aside survives node failure gracefully: a fresh empty node just means more cache misses until it repopulates, the application keeps working
Write-through: write to database → write same value to cache — the cache is never stale, at the cost of a cache write on every database write
Write-through alone leaves gaps: a new or replaced node has no data until each key is written again — pairing it with cache-aside covers this
TTL (time to live) expires a key after N seconds; an expired key reads as a miss — TTL bounds staleness but does not guarantee freshness at every instant
Invalidation (deleting or overwriting a key on the exact write that changes its source data) removes stale data immediately, rather than waiting out a TTL

Cache-aside vs write-through — trade-offs

Cache-aside vs write-through — trade-offs
Property	Cache-aside (lazy loading)	Write-through
When cache is populated	On a read miss	On every database write
Staleness	Possible until next miss or TTL expiry	Never stale (updated with every write)
Extra cost	Cache-miss penalty: 3 trips instead of 1	Cache-write penalty on every database write
New/replaced node behavior	Repopulates itself from misses — app keeps working	Missing data until each key is written again
Wasted cache space	Low — only requested data is cached	Higher — data that is never read is still cached

Cache-aside vs write-through

Cache-aside

Cache filled only on a read miss
Cache miss = 3 trips: cache, database, cache
Node failure just means more misses, not an outage

Write-through

Cache updated on every database write
Cache is never stale
A fresh node has gaps until each key is rewritten

Signature

Cache-aside (read-fill, can stale) vs write-through (write-fill, never stale) + TTL (staleness bound)

Cache-aside: fill on read miss, 3-trip miss penalty, survives node failure gracefully, can go stale. Write-through: fill on every write, never stale, leaves gaps on a fresh node, wastes space on unread data. TTL bounds staleness for either; invalidation on write removes it immediately instead of waiting.

3.Cache Stampede Prevention and Distributed Locks

A cache stampede happens when a popular key expires and many concurrent requests all miss at once, sending every one of them to the database simultaneously. A distributed lock (SET key value NX PX ttl) lets only one process rebuild the key while others wait or serve stale data — but a naive single-key lock is not a hard correctness guarantee, only a best-effort one.

Key features

Cache stampede (thundering herd): a hot key's expiry causes many concurrent requests to miss together, all hitting the database at once instead of one request refilling the cache for the rest
SET key value NX PX ttl acquires a simple lock: NX only sets the key if absent, PX gives it a millisecond expiry so it auto-releases even if the holder crashes
Release safely with a value check, not a plain delete — deleting unconditionally risks removing a lock another process already re-acquired after the original expired
A single-key Redis/Valkey lock is only a best-effort mutual-exclusion primitive: process pauses and clock drift can let two clients both believe they hold the lock
Jittered TTLs (adding a small random offset to each key's expiry) spread out expirations so a single instant does not have to absorb a whole cohort of misses at once
Serving slightly-stale data while one request rebuilds the key is often preferable to letting every request block or hit the database — the lock protects the database, not correctness of the read

No lock vs distributed lock on cache-miss rebuild

No lock

Hot key expires
All concurrent requests miss together
Every one queries the database at once

With SET NX PX lock

Hot key expires
First request acquires the lock and rebuilds it
Others wait briefly or serve the stale value, then re-read

Signature

SET key value NX PX ttl — acquire; check-then-DEL by token — release

A cache stampede is many concurrent misses on one hot key hitting the database at once. SET key value NX PX ttl lets one process rebuild while others wait — release with a value check, not a plain DEL. A single-key lock is best-effort, not a hard guarantee: process pauses or clock drift can still let two holders overlap.

4.Session Storage, Rate Limiting, Counters, and Pub/Sub

Session storage, rate limiting, and counters all reuse a TTL-bearing key plus an atomic operation (SET EX for sessions, INCR for counts); pub/sub is different — it delivers a message to whichever clients are subscribed to a channel right now, with nothing stored in the key space and nothing kept for a client that subscribes later.

Key features

Session storage: a session ID maps to a TTL-bearing key holding the session data — the TTL is the session timeout, and expiry logs the user out automatically without an explicit delete
Rate limiting: INCR atomically increments a per-user, per-time-window counter key; the request is rejected once the count exceeds a threshold before the window's TTL resets it
Counters: INCR/DECR give atomic increment/decrement with no read-modify-write race, used directly for like/dislike counts and similar tallies
Sorted sets (ZADD/ZREVRANGEBYSCORE/ZREVRANK) move ranking computation — like a leaderboard — from the application into the cache itself
Pub/sub (SUBSCRIBE/PUBLISH) delivers a message to every current subscriber of a channel; it has no relation to the key space and does not persist messages for subscribers who join later
Memcached supports none of these beyond plain TTL-bearing key-value storage — sorted sets, atomic INCR/DECR on structures, and pub/sub are Valkey/Redis OSS-only

Command

text

SET session:<id> <data> EX 1800        # session storage, expires in 30 min
INCR ratelimit:<user>:<window>          # rate limiting / counters, atomic
EXPIRE ratelimit:<user>:<window> 60     # cap the counting window
PUBLISH channel message                 # pub/sub, no relation to any key

Session storage and rate limiting both lean on a TTL-bearing key (expiry = timeout / window reset). Counters and rate limits both lean on atomic INCR/DECR to avoid read-modify-write races. Pub/sub is separate from the key space entirely — it delivers to current subscribers only, with nothing persisted for latecomers.

5.Cache Availability and Failover Implications

Multi-AZ on a Valkey/Redis OSS replication group promotes the replica with the least replication lag to primary when the primary fails, usually completing in just a few seconds, and re-points the same primary endpoint via DNS so the application does not need to change anything. Because replication is asynchronous, a small amount of data written just before the failure can be lost. Memcached has no replication or automatic failover at all.

Key features

Multi-AZ requires the replication group to have at least one read replica — a cluster with no replica has nothing to fail over to
On primary failure, the replica with the least replication lag is promoted; writes can resume as soon as promotion completes, typically just a few seconds
The application keeps using the same primary endpoint — ElastiCache propagates the promoted replica's DNS to that endpoint, so no endpoint change is needed for writes or reads through it
Redis/Valkey replication is asynchronous, so a failover can lose a small amount of data written to the old primary just before it failed
If the primary and read replicas all fail together, the entire cluster is recreated and all data in it is lost — a rare but real scenario
Memcached has no replication and no automatic failover — a failed Memcached node is simply replaced with an empty one, with nothing to promote

Failure without Multi-AZ vs with Multi-AZ

Without Multi-AZ

Failed primary must be fully recreated and reprovisioned
No promotion — this takes materially longer
Writes are unavailable until the new primary is ready

With Multi-AZ

Least-lagging replica is promoted to primary
Typically just a few seconds to resume writes
Same primary endpoint, no application change needed

Signature

Multi-AZ: promote least-lagging replica → same primary endpoint via DNS → typically seconds

Multi-AZ promotes the least-lagging replica on primary failure, typically in a few seconds, and re-points the same primary endpoint via DNS — no application change needed. Replication is asynchronous, so a small amount of just-written data can be lost. Memcached has no replication or failover at all.

6.A Cache Is Not the System of Record

A cache is meant to be treated as expendable: it should always be safe to lose it and rebuild from the real data store. By definition, cached data should be considered stale — using ElastiCache as the only place data lives means a node failure, eviction, or restart can destroy data with no other copy, unless durability is deliberately configured and chosen for that purpose.

Key features

AWS documentation states plainly that "by definition, cached data is stale data" and should always be treated as such, regardless of whether it happens to be current at a given moment
A cache node replacement (planned maintenance, failure, or scaling) can start empty — data that lived only there is gone unless a real data store still holds it
Memcached in particular has no replication, no automatic failover, and no durable persistence — a node loss is an unconditional data loss for anything cached only there
Even Valkey/Redis OSS Multi-AZ failover uses asynchronous replication by default, so a small window of very recent writes can be lost during a failover
ElastiCache does offer an explicit exception: Valkey durability (Multi-AZ transactional log, synchronous or asynchronous writes) is designed for genuine system-of-record use cases — knowledge bases, agent memory, payment tokenization — but this requires deliberately enabling it, not just running a cache
Absent that explicit durability configuration, the safe default is: anything only in the cache must be reproducible from the database or another source of truth

Safe: a rebuildable copy vs unsafe: the only copy

Safe design

db.insert() writes the durable copy first
cache.set() is a disposable accelerator
Losing the cache loses nothing

Unsafe design

cache.append() — nothing else stores this
A node failure or eviction destroys it permanently
No error signals the loss

Signature

Cache = expendable, rebuildable copy. System of record = durable store (or Valkey durability, deliberately enabled).

A cache is expendable by design — it must always be safe to lose and rebuild from a real data store. Treat cached data as stale by definition. The one sanctioned exception is Valkey durability, deliberately enabled with synchronous writes for a genuine system-of-record use case — not the default behavior of any ElastiCache cluster.

Spotted a mistake on this page? Tell us.

Read Sheet