ElastiCache, MemoryDB, DAX, and Buffering versus Cache versus Replicas

Caching, buffering, and replicas are different levers

SAP-C02 Task 2.5 explicitly lists caching, buffering, and replicas as performance patterns. Mixing them is the most common professional miss.

• A cache stores hot data in memory so the next read does not hit the system of record. It can be stale. Losing a pure cache should be recoverable by refetching.
• A buffer (usually Amazon Simple Queue Service (Amazon SQS)) absorbs a burst of writes or work items so producers do not block and consumers can scale independently. The buffer is not a lookup table.
• A replica is another copy of a database (Aurora/RDS read replica, DynamoDB Global Table replica, ElastiCache replica node) that serves reads with replication lag. It still speaks the database protocol.

Session cache for a global web fleet is ElastiCache. A flash-sale order spike that must not drop POSTs is SQS (often with Auto Scaling consumers). A reporting dashboard hammering the same Aurora cluster is a read replica—or a cache in front of the queries, if you can tolerate TTL semantics. Putting CloudFront in front of a private session store does not help; putting SQS in front of a read-heavy catalog does not help.

ElastiCache engines: Valkey, Redis OSS, Memcached

Amazon ElastiCache is the managed in-memory service. Current engines are Valkey, Redis OSS, and Memcached. AWS documents Memcached when you want the simplest model, large multi-core nodes, easy add/remove of nodes, and object caching without replica failover. Choose Valkey or Redis OSS when you need replication and failover, pub/sub, sorted sets, hashes, geospatial indexes, backup/restore on node-based clusters, encryption in transit, and (on later Valkey versions) extras such as data tiering on r6gd, bloom filters, or vector search.

For most new SAP-C02-style session and leaderboard designs, Valkey or Redis OSS is the engine. Memcached remains correct when the application already uses a Memcached client, keys are disposable, and horizontal scale-out without replicas is enough. Node-based Memcached does not offer the replica/auto-failover story; serverless Memcached is the documented exception for backup on the Memcached side.

Lazy loading (cache-aside) fills the cache on miss and is resilient to stale writes if you delete or TTL keys on update. Write-through updates the cache on every write and reduces miss storms at the cost of extra write latency. TTL is mandatory for any key that can change; a session cache without expiry becomes a memory leak. Data tiering (Redis OSS/Valkey 6.2+ on r6gd) moves cold keys to local SSD when the working set exceeds RAM—useful, but not a substitute for picking the right node size on a latency-sensitive trading book.

Cluster mode, Global Datastore, and MemoryDB

Cluster mode disabled means one shard: one primary and up to five replicas. Vertical scale is a larger node type; reads can fan out to replicas. The memory ceiling is that one primary. Cluster mode enabled shards the keyspace across many shards (AWS documents up to 500 for supported Valkey/Redis OSS versions). Clients must be cluster-aware. Cross-slot operations are constrained. Enable cluster mode when a single primary cannot hold the dataset or the write throughput. Migrating from disabled to enabled is a design event, not a checkbox midday.

Global Datastore (Valkey/Redis) replicates a cache across Regions for read locality. It is still a cache topology, not a multi-Region system of record. AWS documents that durability features and Global Datastore are not combined; if you need durable writes and multi-Region active-active, that is Amazon MemoryDB territory.

Amazon MemoryDB is a durable in-memory database with Valkey/Redis compatibility. Writes are acknowledged against a Multi-AZ transactional log. AWS currently tells you to consider MemoryDB when you need multi-Region active-active replication with conflict-free replicated data types (CRDTs). For single-Region durable in-memory data, ElastiCache for Valkey with durability enabled is the documented alternative. Use MemoryDB when the in-memory store is the primary database (for example a hot wallet ledger keyed like Redis). Use ElastiCache when a durable database (Aurora, DynamoDB, RDS) remains the source of truth and memory is an accelerator.

ElastiCache Serverless removes node math for spiky session traffic; node-based clusters remain the usual choice when you need specific engine features, reserved-node economics, or fine placement. Do not quote unpublished dollar amounts; compare patterns, not price lists.

DAX versus ElastiCache

DynamoDB Accelerator (DAX) is a write-through/write-around cache that speaks the DynamoDB API. Eventually consistent reads drop from single-digit milliseconds toward microseconds. You change the client endpoint, not your data model. DAX shines for hot keys, bursty read-heavy tables, and repeated item gets. It is a poor fit for strongly consistent reads, write-heavy tables, or low cache-hit-rate scans. DAX metadata about unbounded top-level attribute names can exhaust memory—do not use timestamps as attribute names.

Put ElastiCache in front of DynamoDB only when you need Redis data structures, a cache shared with non-DynamoDB sources, or logic DAX does not provide. That path is application-managed cache-aside. Putting DAX in front of Aurora is impossible; putting ElastiCache in front of Aurora is normal. Putting DAX in front of a session cookie blob in S3 is the wrong service family.

Buffering versus cache versus read replica

Walk the exam stem through this test:

1. Are producers blocking or dropping writes because consumers are slow? SQS (standard for throughput; FIFO when order and exactly-once processing within a group matter). Optionally Amazon Kinesis Data Streams if multiple consumers need the same ordered firehose of events. That is buffering.
2. Are the same keys read orders of magnitude more than they are written, and is stale-for-TTL acceptable? ElastiCache (or DAX if the store is DynamoDB). That is caching. Session stores, shopping carts, leaderboards (sorted sets), and feature flags live here.
3. Are SQL read queries saturating a primary while writes are fine? Read replicas (Aurora reader endpoints, RDS replicas). Replicas lag. They do not give you Redis sorted sets. They do not absorb a write storm.

Anti-patterns: using SQS as a session lookup (queues are not random access); using a read replica as a sub-millisecond session cache; using ElastiCache as the only copy of financial postings without a durability story; using CloudFront to cache per-user session JSON with a long TTL.

Session cache and trading sketches

Web fleet sessions: ElastiCache for Valkey, cluster mode enabled if the keyspace will exceed one node, Multi-AZ with automatic failover, short TTL, cache-aside on login. Do not use Memcached if you need replica promotion during an AZ event. Do not use MemoryDB unless the session store is declared the system of record.

Latency-sensitive trading reads of reference data in DynamoDB: DAX for eventually consistent microsecond gets of instruments that rarely change. The matching engine’s working book, if it is a Redis sorted set with durability requirements across Regions, is MemoryDB active-active—or a purpose-built trading datastore, not Memcached. Market-data fan-out of ticks is a streaming or pub/sub problem (Kinesis, Redis pub/sub), not SQS if every subscriber needs the same tick. Order ingress that must never drop during a spike is SQS or a journaled stream in front of the matcher. Professional answers name which of those three jobs the stem actually described.