Certopolis

AWS Certified Solutions Architect – Associate

ElastiCache Redis vs Memcached, lazy loading vs write-through

Choose Memcached for the simplest cache of objects on large multi-threaded nodes that you scale out and in. Choose Valkey or Redis OSS when you need replication, automatic failover, backups, pub/sub, sorted sets or other complex data types. Then pick a strategy: lazy loading caches only what is read but can go stale, write-through keeps the cache current but leaves new nodes empty, and a TTL on each write limits staleness.

Choosing the engine

ElastiCache supports Valkey, Memcached and Redis OSS. All three are in-memory key-value stores. AWS says to choose Memcached when you need the simplest model, large nodes with multiple cores or threads, the ability to add and remove nodes as demand changes, and object caching. Memcached is multi-threaded; Valkey and Redis OSS are not.

Valkey and Redis OSS support complex data types such as sets, sorted sets, lists, hashes and geospatial indexes. They support replication for high availability, backup and restore, and pub/sub. Memcached on node-based clusters has none of these. Automatic failover is optional with cluster mode disabled and required with cluster mode enabled. Cluster mode enabled also partitions data across shards and allows online resharding.

Recent Valkey versions add features such as vector search (8.2) and full-text search and durability through a Multi-AZ transactional log (9.0). Data tiering between memory and SSD uses the r6gd node type.

Lazy loading

With lazy loading, the application reads from the cache first. On a miss it reads the database and writes the result to the cache. Only data that is requested gets cached, and a failed node is not fatal: a new, empty node fills up as misses come in.

The costs are a miss penalty of three trips (cache, database, cache write) and stale data, because nothing updates the cache when the database changes.

Write-through and TTL

With write-through, every database write also writes the cache, so cached data is never stale. Each write takes two trips. The costs are missing data on a new node until each item is written again, and cache churn, because most written data is never read. AWS says to reduce the missing-data problem by adding lazy loading alongside write-through.

A time to live (TTL) sets how many seconds a key lasts. An expired key is treated as a miss, so the application refetches it from the database. Adding a TTL to each write keeps data from getting too stale and clears out unread data, though it does not guarantee data is never stale.

Where the exam catches people

  • Believing Memcached can fail over to a replica: Memcached node-based clusters have no replication or automatic failover; use Valkey or Redis OSS.
  • Believing Valkey or Redis OSS is always the better pick: for simple, rebuildable objects on multi-core nodes that scale out and in, AWS points to Memcached.
  • Believing write-through means a new node is warm: it holds nothing until each item is written again, so pair it with lazy loading.
  • Believing lazy loading keeps data fresh: the cache is not updated when the database changes; add a TTL to bound staleness.
  • Believing automatic failover is optional with cluster mode enabled: it is required there and optional only with cluster mode disabled.

Written from Amazon Web Services's documentation

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

  1. A workload caches large numbers of simple objects, needs to add and remove cache nodes as load changes, and benefits from nodes with many cores. Cached data can be rebuilt from the database at any time. A solutions architect must choose the ElastiCache engine. Which approach will meet these requirements?

    Right. In the game that’s Renown for your Design High-Performing Architectures building.

    Not that one: A is right. In the game your Design High-Performing Architectures building would lose a little Renown, and this question would come back later.

    Show the full explanation and doc quotes

    The comparison table confirms the differentiator: "Multi-threaded" is Yes for Memcached and No for both Valkey and Redis OSS modes. Because the data can be rebuilt, the replication and persistence that would otherwise argue for Valkey or Redis OSS buy nothing here.

    Written from docs.aws.amazon.com/AmazonElastiCache/latest/dg/SelectEngine.html

  2. A product catalogue uses ElastiCache with a write-through strategy: every database write also writes the cache. After a scaling event adds an empty node, a share of reads return nothing from the cache and the application shows missing products until those records are next updated. The application must show every product after a node is added, without waiting for records to be updated. Which solution meets these requirements?

    Right. In the game that’s Renown for your Design High-Performing Architectures building.

    Not that one: D is right. In the game your Design High-Performing Architectures building would lose a little Renown, and this question would come back later.

    Written from docs.aws.amazon.com/AmazonElastiCache/latest/dg/Strategies.html

  3. A reporting page reads from ElastiCache with lazy loading. Users report that the page occasionally shows figures that the database changed hours earlier, and the team wants to bound how stale a cached figure can be without rewriting how the application writes data. Which solution meets these requirements?

    Right. In the game that’s Renown for your Design High-Performing Architectures building.

    Not that one: A is right. In the game your Design High-Performing Architectures building would lose a little Renown, and this question would come back later.

    Show the full explanation and doc quotes

    AWS states that "lazy loading allows for stale data but doesn't fail with empty nodes" and that "by adding a time to live (TTL) value to each write, you can have the advantages of each strategy", defining TTL as "an integer value that specifies the number of seconds until the key expires". The behaviour on expiry is what closes the gap: "when an application attempts to read an expired key, it is treated as though the key is not found. The database is queried for the key and the cache is updated." AWS is careful about what it buys: "this approach doesn't guarantee that a value isn't stale. However, it keeps data from getting too stale."

    Written from docs.aws.amazon.com/AmazonElastiCache/latest/dg/Strategies.html