12 — ElastiCache: Putting Memory Between the Database and the App

"Managed Redis, for when the database is slow" was my entire ElastiCache story, and it mixed up two different jobs. The split that landed: ElastiCache is a managed in-memory layer I put between the application and the database to absorb the reads the database has no business serving, and the engine choice — Redis or Memcached — decides whether I get a cache or something closer to a fast data structure server [1]. Once I separated those two uses, picking the engine and sizing the cluster stopped being guesswork.

Why an in-memory layer exists at all

The problem ElastiCache solves is straightforward: disk-based databases are fast, but memory is faster — microseconds versus milliseconds. The workloads that hurt are the ones hitting the same rows thousands of times a second (a hot config value, a session, a leaderboard), each paying the disk round-trip when the data barely changes. A cache absorbs those reads; the database handles writes and the occasional cold read. The win is latency on the hot path and load off the primary.

The trade-off is the usual one: memory is more expensive per GB than disk, so the cache only earns its keep on data that's read far more than it's written. Cache everything, and the bill outpaces the benefit; cache nothing, and the database groans.

The two engines

ElastiCache supports two open-source engines, and they sit at genuinely different spots [1]:

• Memcached — a simple, multi-threaded key-value cache. Strings in, strings out, with a TTL. No persistence, no replication, no data structures. It is just a cache, and for pure caching workloads it's simple and fast.
• Redis — a single-threaded (mostly) in-memory data store with strings, lists, sets, sorted sets, hashes, pub/sub, persistence, replication, and clustering. It's a cache and a session store and a leaderboard engine and a lightweight queue.

The practical rule I use: reach for Redis unless there's a specific reason not to. Memcached's simplicity is real, but Redis's extra features (persistence, replication, atomic operations on data structures) cover almost every caching-adjacent need without giving up much raw throughput. Most new projects default to Redis, and the roadmap's coverage of Memcached is mostly for completeness.

The two jobs Redis does

Beyond "make reads faster," Redis-on-ElastiCache shows up in two specific shapes:

• Database read cache — the app checks Redis first; on a hit it returns, on a miss it queries the database and back-fills. Reduces load on RDS/DynamoDB for read-heavy patterns.
• Session store — user sessions live in Redis because it's fast, can be replicated across AZs, and survives instance restarts better than local memory. Multiple app instances share one session store, which is the enabling trick for stateless, horizontally-scaled web tiers.

The cache-aside pattern is the most common:

Quotas and the operational shape

ElastiCache has account-level quotas on clusters, nodes, parameter groups, and subnet groups, varying by region and raisable via support [2]. The practical operational concern is eviction policy — when the cache is full, what gets dropped? Redis options include noeviction (writes fail when full), allkeys-lru (drop least-recently-used, the usual cache choice), and volatile-lru (drop least-recently-used among keys with a TTL). The right policy depends on whether the cache is allowed to lose data; for a pure read cache, allkeys-lru is almost always correct.

The other decision is node size and replication. Redis supports cluster mode with sharding and replicas across AZs, which is what makes it usable as a session store that survives a node loss. Memcached scales horizontally too but without replication — a node loss there is a cache miss storm until the data is reloaded.

How I use this

ElastiCache earns its line in the architecture when the same data is read many times more than it's written. My standing patterns: a Redis read cache in front of RDS for hot read-heavy queries, with allkeys-lru and a TTL that matches how stale the app can tolerate; Redis as the session store for any horizontally-scaled web tier (so any app instance can serve any user); and Memcached essentially never, because Redis covers its use cases and adds replication. The discipline is measurement, not vibes — I add the cache only after I can name the query that's slow and confirm the read/write ratio favors caching. Adding a cache to a write-heavy or random-read workload just adds a failure surface and a bill without removing load from the database.

References

[1] Amazon Web Services, "What is Amazon ElastiCache?," ElastiCache User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/WhatIs.html

[2] Amazon Web Services, "ElastiCache quotas," ElastiCache Management Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/quota-limits.html