SAA-C03 Practice Question 17: DynamoDB DAX Caching
AWS Certified Solutions Architect – Associate (SAA-C03) · Test 2 · question 7 of 10
A real-time bidding platform stores advertiser profiles in an Amazon DynamoDB table. The workload is overwhelmingly reads, and a small set of popular profiles is read thousands of times per second. DynamoDB returns these reads in single-digit milliseconds, but the bidding engine now needs microsecond response times.
The engine can tolerate eventually consistent reads, and the developers want to keep the existing DynamoDB API calls with as few code changes as possible. Which solution should the architect recommend?
Show answer and explanation
Answer:
DynamoDB Accelerator (DAX) is an in-memory cache built for DynamoDB. For eventually consistent reads it cuts response times by an order of magnitude, from single-digit milliseconds to microseconds. It is API-compatible with DynamoDB, so the application swaps in the DAX client and keeps making the same GetItem and Query calls, with only minimal code changes. A few hot items read over and over is the ideal DAX workload, since the cache hit rate will be high. Real-time bidding is one of the example use cases AWS documents for DAX.
Option A can also reach sub-millisecond latency, but it misses the second requirement. ElastiCache does not speak the DynamoDB API, so developers would have to write and maintain cache-aside logic for every lookup, including population, expiry, and invalidation. That is substantial code change, not minimal.
Option B deals with capacity, not latency. On-demand mode prevents throttling as traffic grows, but every read is still served by DynamoDB in milliseconds.
Option D changes which attributes you can query efficiently. An index is still read from DynamoDB storage at the same millisecond latency, and it does nothing for repeated reads of the same hot items.
Reference: In-memory acceleration with DynamoDB Accelerator (DAX)