A read-heavy product catalogue runs on Amazon DynamoDB, and a service team needs to cut single-digit-millisecond read latency to microseconds for repeated reads of the same items, while keeping their existing DynamoDB API calls unchanged. Which fully managed caching option fits this requirement with the least application rework?
- APut DynamoDB Accelerator in front of the table as a write-through cache so repeated item reads return from DAX in microseconds. Correct
- BFront the table with an Amazon ElastiCache for Memcached cluster and add cache-aside lookups in the application before each DynamoDB read.
- CCreate DynamoDB global secondary indexes on the most-read attributes so that repeated catalogue reads resolve faster from the indexes.
- DEnable DynamoDB point-in-time recovery and rely on its retained copies to serve the repeated catalogue reads at lower latency.
Why A is correct: DAX is a managed in-memory cache purpose-built for DynamoDB that uses the same API, returning cached items in microseconds with no cache-aside code to write.
Why B is wrong: ElastiCache could cache items, but it needs bespoke cache-aside code and its own key management, which contradicts the requirement to keep the DynamoDB API calls unchanged.
Why C is wrong: Global secondary indexes support different query patterns but still read from DynamoDB storage at millisecond latency, so they cannot deliver the microsecond reads being asked for.
Why D is wrong: Point-in-time recovery is a backup and restore feature that protects against data loss and plays no role in read latency, so it cannot meet the performance goal at all.