Configuring AWS ElastiCache: where the cache breaks
Configuring AWS ElastiCache starts not with launching a node but with calculation: the cache is placed in front of the database to remove the database bottleneck—repeated queries and aggregates are served from memory rather than disk.
With an incorrect configuration, the service itself becomes a point of failure: Redis cache failures manifest as increased response time and an avalanche of requests crashing down on the database.
The most common cause is cache memory overflow. The limit is set without headroom for overhead structures and fragmentation, and the eviction policy is left at default.
If it prohibits key deletion, writes begin to fail with errors; if it deletes everything indiscriminately, hot data is flushed out of the cache, and the database receives exactly the traffic you were trying to avoid.
The second scenario is a cold cache start. After a reset, node restart, or manual flush, the cache is empty, and all traffic goes to the database at once.
Without warming and concurrency limiting, the database cannot withstand the peak, even though formally you “only flushed the cache.”
The third is a node without replication. A failure takes away both the warmed key set and some records, and recovery starts from scratch. A replica and a failover procedure turn this into brief degradation instead of downtime.
These are the scenarios we work through before configuration: we calculate the volume of hot data and memory headroom, define eviction and restart rules, set up a replica with automatic failover—we work through how each of them is addressed in practice.
What a dedicated cache provides: response, load, failures
The first thing visible in metrics after moving reads to ElastiCache is a drop in the share of slow queries.
A typical load profile goes from a few percent of requests to hot keys down to tenths of a percent, and application response time stops depending on whether a request hit a contention lock on the primary database.
The upper percentile stops “drifting” during active hours, and this is visible not in synthetic tests but in production traffic.
The second effect is offloading the primary database during peak hours. Repeated queries for reference data, sessions, counters, and permissions go to the cache, so the database primarily handles writes and unique queries rather than the same set of reads.
Headroom for connections and disk operations remains for growth instead of being consumed by repeats.
The third is fault tolerance of the cache itself.
A configuration with replicas in different Availability Zones and automatic failover turns the loss of a node into a brief spike of misses rather than a service outage: on a miss, client logic goes to the database and refills the cache.
With correctly set key TTLs and protection against concurrent recomputation, this does not turn into an avalanche of requests.
The fourth is removing a class of overload failures. Previously, a traffic peak meant a queue of requests and timeouts; now the extra load falls on the cache, which scales horizontally.
Instead of degrading to unavailability, the service keeps response time within the norm, and traffic growth stops being an incident.
ElastiCache clusters: operating modes and topologies
A cache in AWS ElastiCache can be assembled into several topologies, and ElastiCache modes determine not so much speed as the failure class.
A single node provides minimal network hops, but losing the host means complete cache loss: the application goes to the database all at once and finishes it off with a spike of requests.
Cache replication closes this gap—the replica node is promoted automatically, and the client reconnects to the new address within seconds.
Cache sharding solves a different problem: keys are distributed across slots, and memory and throughput grow horizontally. The limitation is that some cross-slot operations are unavailable, and client libraries need explicit enabling of cluster topology support.
| Option | When it fits | Limitations |
|---|---|---|
| Single node | Test environments, data is cheaper to recompute | No automatic failover: failure = cache loss |
| Replication with automatic failover | Sessions, carts, where downtime is noticeable | A replica scales reads, not writes |
| Cache sharding | Dataset does not fit in one node | More complex client, some cross-slot operations unavailable |
| In-application cache | Hot reference data with infrequent changes | Not shared between instances, invalidation requires broadcasting |
The topology is chosen based on the data, not the load at the moment: for most production scenarios, two shards with a replica in each are enough—this provides failover to a standby node and headroom for growth. We test failure handling in a staging environment, not in production.
How implementation proceeds: from audit to handover
Configuring AWS ElastiCache starts from the load profile, not from creating a cluster. First we capture what and how often the application reads, how long data lives, and what happens on a miss—the placement scheme, memory volume, and eviction rules depend on this.
- Load audit. We capture the application and database access profile: read-to-write ratio, hot keys, spread of value sizes, daily peaks. The output is requirements for memory volume and operations per second.
- Cache placement scheme. We decide what to cache—sessions, reference data, results of heavy queries—where to set a TTL and where to use explicit invalidation. We separate key spaces by service so one does not evict another’s data.
- Cluster configuration. We set up a configuration with replicas and automatic failover, place nodes in different Availability Zones, and enable encryption both in transit and at rest. We define the eviction policy based on audit results, not defaults.
- Access and isolation. The cluster lives in private subnets, access is via security groups and credentials from a secrets store with rotation. We separately verify that the test environment cannot see production data.
- Fault tolerance testing. We drain a node in a controlled manner, emulate an Availability Zone failure, and observe how the application handles a miss and how quickly the cache refills. We record recovery time and behavior on memory overflow.
- Documentation handover. We provide the placement scheme, cluster parameters, eviction rules, key rotation procedure, and instructions for typical operations—scaling, upgrading, version rollback.
Documentation and artifacts that remain with you
Configuring AWS ElastiCache ends not with the cluster status but with a package of artifacts that your team uses to operate the cache without us. Everything is stored in your repository and knowledge base, and we hand it over with a walkthrough on a call.
- Cluster diagram — topology of shards and replicas, distribution across Availability Zones, endpoints, failover procedure when a node fails.
- Cache access policies — roles and security groups, encryption in transit and at rest, credential rotation, network access boundaries.
- Cache warming procedure — order of filling after restart, load limitation on the data source, indicator of completed warming.
- Flush and invalidation procedure — what and when we evict, how mass clearing does not bring down the database, how we verify the result.
- On-call shift instructions — key metrics, their interpretation, typical sequence of actions, and the point at which to call us.
- Infrastructure documentation — configuration description in the repository, group parameters, revision history, and change procedure.
- Testing report — load and failure scenarios run, limitations found, what was deliberately left outside the perimeter.
The package is designed for an engineer seeing the cluster for the first time: it can be used to run an on-call shift, roll back a change, and justify an edit. Before handover, we walk through each document with your team and answer configuration questions.
Case study: how we removed peak load from a product catalog
The starting point
A catalog of 180,000 items with filters and sorting: each list view means dozens of queries to the primary database. During a sale, peak reads hit the ceiling, p95 for serving a product card went over a second, and the share of slow queries stayed at 8–9%.
Some carts were lost to timeouts, and the database left no headroom for writes—orders and stock updates queued behind reads.
A separate pain point was cache node failure. The cluster ran in a single zone without a replica: on restart, hot keys cooled all at once, all traffic fell on the database, and recovery took up to 40 minutes of manual work.
What we changed and what we got
We deployed an AWS ElastiCache cluster with a replica in another Availability Zone and automatic failover when a node fails.
We cached not “everything in a row” but hot query results—product cards, catalog slices, counters—with TTLs by data type and different eviction policies so rare keys would not push out popular ones. Warming after each release and a maximum value size limit removed the read spike at startup.
Measurements over a month: cache hit rate 94–97%, reads to the primary database fell by 6 times, slow queries from 9% to 0.3%. A node failure is now survived in 30–40 seconds without manual actions: the replica is promoted, and the catalog continues to respond from the cache.
Previously, such an incident meant catalog degradation and 40 minutes of manual recovery—now it is a line in monitoring.
We left memory and hit-rate alerts under monitoring, plus a TTL review for assortment changes—so the cache does not turn into a source of stale data.
How Redis differs from Memcached in caching
The difference starts with the data model. Memcached is a flat key-value store: values are strings or binary blobs, and the client serializes structures itself.
Redis works with types—hashes, lists, sorted sets, counters, streams: incrementing, fetching a range from a queue, or getting a top rating are performed server-side in a single operation, without a read-modify-write loop and races between clients.
State persistence is the second divide. Memcached keeps data only in memory: no replicas, no disk snapshots, so restarting a node or evicting keys sends the application back to the database entirely.
Redis snapshots state to disk, maintains a change log, and keeps replicas—after a failure, the cache warms partially, not from scratch.
Cluster mode differs fundamentally. Memcached scales on the client side: the library itself distributes keys across nodes, and when their number changes, some keys change owner—the cache layer responds with misses, and the database gets a spike.
In Redis cluster mode, key distribution across nodes and load transfer when a replica fails are performed server-side and hidden from the application.
A mistake in choice is possible in both directions. Memcached is appropriate where cache loss is not critical—page fragments, sessions; but queues, locks, and counters on it turn into hand-rolled client-side logic.
Redis is chosen for a dozen keys and you pay with replicas, memory, and maintenance. In ElastiCache, the engine is set when the cluster is created and cannot be changed on the fly: switching means a new cluster and a newly warmed cache.
Customers’ technical concerns before starting
Concerns before the start are usually the same: will code need to be changed, what happens if a node fails, how to avoid serving stale data to the user, who will get access to the cache.
We answer briefly; we go through details on a call using your architecture—taking into account an already running unstable cache, if there is one.
Do we need to change the application code?
In most cases, no changes to the application code are needed: the Redis and Memcached client libraries are standard, and only the connection address in the configuration changes.
Logic has to be rewritten if you have your own key schemes or non-standard response parsing—we identify such places in advance.
What about stale data in the cache?
For each key type, we set a TTL and eviction policy so memory does not get clogged with dead records. Where freshness matters, the record is invalidated immediately after a change in the database—stale data in the cache does not survive until the next read.
Who and how will get access to the cache?
We place the cache in private subnets with no internet access, restrict access with security groups, and encrypt traffic. Passwords and keys are stored in a secrets store and rotated; no administrative access remains from the application.
We already have a cache, but it is unstable—do we need to redo everything?
First we capture metrics on memory, latency, and connection drops, and separate a configuration error from a resource shortage. Then we either fix the current cluster or migrate data to a new one without service downtime—keys lost during migration are compensated by warming.
Let’s discuss the task: what to clarify before work begins
Before naming timelines and scope, we need inputs on the load and current architecture. Usually one conversation with your engineer and a description of how the application accesses AWS ElastiCache is enough—we clarify the rest ourselves.
Based on the results, we come back with a work estimate, a phased implementation plan, and a diagram of the future cluster.
What to keep at hand when discussing the task:
- load profile—how many requests per second the peak handles and how much higher it is than average;
- volume and structure of data in the cache: what is stored, how often it changes, which keys live the longest;
- application behavior on node failure: what happens when the cache becomes unavailable;
- data persistence requirements: is it acceptable to lose some data on restart, or is disk persistence needed;
- network perimeter: which network the services live in and who needs access to the cache;
- target metrics: response time, cache hit rate, recovery time after failure;
- constraints: change windows, access, security and audit requirements.
If some inputs are missing, that’s fine: we’ll gather some together, and some we’ll capture with measurements in your environment. Describe the task in free form—we’ll come back with an estimate, an implementation plan, and a cluster diagram you can discuss with your team.