Choosing Data Stores and Caching

What it is

No single AWS data store fits every job. You choose by access pattern: how the application reads and writes data, how fast, how big, and how it asks questions.

A cache keeps copies of hot data in fast memory so repeated reads skip the slower store. It lowers latency and protects the database. The right cache depends on which data store sits behind it.

How it works

Matching the store to the access pattern

Some rules of thumb help with scenario questions.

• If every query names the key, DynamoDB fits. If the questions are unpredictable or need joins, a relational database fits better.
• A DynamoDB item is limited to 400 KB. Keep large objects in S3 and store the S3 key in the item.
• A single S3 PUT handles up to 5 GB. For bigger objects, and for large uploads in general, use multipart upload.
• Aurora is a MySQL and PostgreSQL compatible relational engine and is chosen when RDS needs higher performance and availability.

Caching strategies

Lazy loading (also called cache aside) is the common pattern. The application checks the cache, and on a miss it reads the database and writes the result to the cache with a TTL.

def get_product(pid):
    item = cache.get(pid)
    if item is None:                  # cache miss
        item = db.get(pid)
        cache.set(pid, item, ex=300)  # expire after 300 seconds
    return item

Only requested data is cached, so a node failure is not fatal. The first read after a miss is slower, and data can be stale until the TTL ends.

Write-through updates the cache every time the database is written. Data stays fresh, but you cache items that may never be read and every write costs more.

A TTL bounds staleness in both patterns. A short TTL gives fresher data and a lower hit rate.

Which cache for which store

DAX has an item cache for GetItem and BatchGetItem, and a query cache for Query and Scan. Writes go through DAX to the table. The default item cache TTL is 5 minutes.

DAX caches only eventually consistent reads. A strongly consistent read passes through to DynamoDB and is not cached, so an application that needs those reads gets little help from DAX.

ElastiCache runs two engine families. Valkey and Redis OSS offer rich data structures, replication, snapshots and pub/sub, which suits session stores and leaderboards. Memcached is a simple, multithreaded key value cache without replication or persistence.

How the exam asks about this

• "A read heavy DynamoDB table needs microsecond reads with the least code change." -> DAX.
• "Complex SQL results are read repeatedly and the RDS instance is overloaded." -> ElastiCache with lazy loading in the application.
• "Users upload 2 GB videos that must be stored cheaply and served later." -> Amazon S3 with multipart upload.