SysPad › Lessons › database lessons › Amazon ElastiCache

How Amazon ElastiCache works

AWS-managed in-memory store for caching, sessions, pub/sub, and leaderboards. Runs the Valkey (default), Redis OSS, or Memcached engine. Sub-millisecond latency, with clustering and replication for HA. Mode picks which workload is simulated: cache (hits absorbed, misses forwarded) or pub/sub (each publish fanned out to every subscriber). For self-hosted, use the generic Redis component.

A cache is a bet: that what you just fetched, you’ll fetch again soon. ElastiCache keeps that data in RAM so reads come back in under a millisecond. The interesting part isn’t the speed, it’s the two hard questions every cache forces on you: what to do on a miss, and what to throw away when memory runs out.

What you will learn

What actually happens on a cache "miss", and why can a flood of misses be dangerous?
Why is a single-threaded server one of the fastest things in your stack?
When memory fills up, what does Redis throw away, and how do you control that?
When does a cache become a liability you can’t treat as your source of truth?

A cache is a bet (the cache-aside pattern)

The most common pattern is cache-aside: the app checks Redis first. A hit returns instantly. A miss means the app reads the real database, then stores the answer in Redis so the next request is a hit.

ElastiCache now ships this engine as both Valkey and Redis OSS (Valkey is the cheaper default). Everything here applies identically to both.

What’s a "cache stampede", and why does it bite at the worst moment?

If a popular key expires and a thousand requests miss at the same instant, all thousand stampede the database at once, sometimes hard enough to take it down (the "thundering herd"). Mitigations: stagger TTLs, refresh hot keys before they expire, or let just one request rebuild the value while others wait.

Why a single thread is so fast

Two things make Redis quick. First, the data is in RAM, no disk seek. Second, it executes commands on a single thread, one at a time, with no locking or contention overhead.

That sounds like a limitation, but in-memory operations are so fast that one core churns through enormous request rates, and every command is effectively atomic.

⚓ Ideal for sessions, rate limiters, leaderboards, and read-through caches in front of a slower database.

Finite memory: eviction and TTL

RAM is finite, so you decide what happens when it fills. A TTL expires keys after a set time; the maxmemory policy chooses what to drop when full, often least-recently-used (LRU) or least-frequently-used (LFU).

What if the policy is set to "noeviction"?

With noeviction, once memory is full Redis stops accepting writes and returns errors instead of dropping anything. That’s correct for some queue-like uses but a nasty surprise for a cache, which generally wants an LRU/LFU policy so it can keep taking new keys.

Replication and failover

For high availability, a node group has one primary plus one or more replicas kept in sync. If the primary fails, ElastiCache promotes a replica automatically (Multi-AZ), usually within seconds.

Replicas can also serve reads, letting you scale read throughput, with the same caveat as any async replica: a replica read may be a touch behind the primary.

Cluster mode: sharding by hash slot

One node’s RAM and one thread eventually aren’t enough. Cluster mode splits the keyspace into 16,384 hash slots and spreads them across multiple shards, each with its own primary (and replicas).

A key is hashed to a slot, and that slot lives on exactly one shard, so the data and the work spread out. This is how Redis scales memory and throughput horizontally.

It’s a cache, not your source of truth

ElastiCache is built for speed, not durability. On a failover or restart, recent data can be lost, and that’s an acceptable trade for a cache whose contents you can always rebuild from the database.

Flashcards

A request hits the cache and the key isn’t there. What does cache-aside do next?: It reads from the backing database, returns that value, and writes it into Redis so the next request for that key is a fast hit.
One very popular key expires and thousands of requests miss at the same instant.: A cache stampede (thundering herd): they all hit the database at once. Stagger TTLs, pre-refresh hot keys, or let a single request rebuild the value.
Redis executes commands on one thread. What property does that hand you?: Each command is effectively atomic, no locks or race conditions between commands, and in-memory speed keeps a single core extremely fast.
Memory is full and a write arrives. Under an allkeys-lru policy, what happens?: Redis evicts the least-recently-used key to make room and accepts the write. Under noeviction it would instead reject the write.
How does a Redis cluster decide which shard owns a given key?: It hashes the key to one of 16,384 hash slots; each slot is assigned to exactly one shard. Adding shards spreads slots, memory, and throughput.
Can you safely store the only copy of a user’s shopping cart in ElastiCache?: No. ElastiCache can lose recent data on failover/restart. Keep the source of truth in a durable store; use MemoryDB if you need in-memory speed with durability.

Sources

Open the SysPad canvas · Official Amazon ElastiCache documentation