SAP-C02 Practice Question 16: DynamoDB Microsecond Read Cache
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 2 · question 6 of 10
A real-time ad bidding service is being designed on Amazon DynamoDB. For every bid request, the service reads a small campaign-settings item and a budget-pacing item, and a relatively small set of popular campaigns accounts for most reads. Load tests show single-digit millisecond read latency from DynamoDB, but the bidding contract requires reads in microseconds. The read capacity bill is also growing quickly because the same items are read millions of times per hour.
Reads that are eventually consistent by up to a few seconds are acceptable. The development team wants to keep using the DynamoDB API it already codes against, without writing cache-population, invalidation, or read-through logic, and wants a managed service rather than cache nodes it operates on EC2. Which solution should the architect choose?
Show answer and explanation
Answer:
DynamoDB Accelerator (DAX) is a managed, in-memory cache that is API-compatible with DynamoDB. It cuts eventually consistent read latency from single-digit milliseconds to microseconds, and AWS lists real-time bidding as a target use case. Because DAX speaks the DynamoDB API, adopting it takes only minimal functional changes. The application swaps in the DAX client, and DAX handles read-through and write-through caching itself. The workload fits DAX well: a small hot set of keys gives the high cache hit rate DAX needs. Offloading those repeated reads also cuts the read capacity units the table must serve, which addresses the cost growth. The stem's tolerance for eventual consistency matters, because DAX serves only eventually consistent reads from cache.
Option B can reach sub-millisecond latency, but it fails the "no cache logic" constraint. A lazy-loading pattern means the team writes the cache-miss path, chooses TTLs, and handles invalidation on writes, all code that DAX makes unnecessary for a DynamoDB-backed app.
Option C changes the billing model and adds Regions, but every read is still a DynamoDB read at millisecond latency, and global tables multiply cost rather than reducing it. Nothing is cached.
Option D makes both problems worse. Strongly consistent reads cost twice the read capacity of eventually consistent reads and can't be served from DAX's cache. A narrower index doesn't change DynamoDB's latency class.
Reference: In-memory acceleration with DynamoDB Accelerator (DAX)