Redis vs. Memcached & Caching Patterns

A Managed In-Memory Cache

ElastiCache is AWS's fully managed in-memory caching service, handling provisioning, patching, failover, and backups for Redis or Memcached — reducing latency and database load for frequently accessed data by serving repeated reads from fast in-memory storage instead of hitting the database every time.

Redis vs. Memcached

Redis supports richer data structures (lists, sets, sorted sets, hashes), persistence, pub/sub, and replication — useful beyond simple caching, for leaderboards, rate limiting, session stores, and messaging. Memcached is simpler and multi-threaded — pure key-value caching, sometimes with a raw single-node throughput edge for that specific use case since it can use multiple cores directly, where Redis's core command processing is largely single-threaded.

Cache-Aside (Lazy Loading)

async function getUser(id) {
  const cached = await redis.get(`user:${id}`)
  if (cached) return JSON.parse(cached)

  const user = await db.query('SELECT * FROM users WHERE id = $1', [id])
  await redis.set(`user:${id}`, JSON.stringify(user), 'EX', 300) // TTL 5 min
  return user
}

The application checks the cache first, falling back to the database on a miss and populating the cache for next time. Write-through is the alternative: updating the cache as part of the same write that updates the database, trading write latency for fresher reads instead of lazy population.

TTL & Cache Stampedes

A TTL bounds how long stale data can linger even if explicit invalidation is missed — a pragmatic complement to invalidation logic, not a replacement for it. When a popular key expires, many concurrent requests can miss the cache simultaneously and hammer the database at once (a cache stampede) — mitigated with staggered TTLs, single-flight locking, or proactive refresh before expiration.