A trading application performs the same handful of DynamoDB reads for popular instruments repeatedly, and the team needs to cut typical read response times from single-digit milliseconds down to microseconds without rewriting the application's DynamoDB API calls or accepting reduced read throughput. Which solution fits, and what tradeoff does it require?
- DynamoDB Accelerator (DAX), an API-compatible in-memory cache that serves eventually consistent reads at microsecond latency, at the cost of not supporting strongly consistent reads through the cache
- ElastiCache for Redis placed in front of DynamoDB, since Redis is API-compatible with DynamoDB's SDK calls and requires no changes to application code
- Increasing the table's provisioned read capacity units until latency drops to microseconds
- Enabling DynamoDB point-in-time recovery, which caches recent reads in memory for faster access
Why A? And why not the others?
Correct answer: A. DynamoDB Accelerator (DAX), an API-compatible in-memory cache that serves eventually consistent reads at microsecond latency, at the cost of not supporting strongly consistent reads through the cache
DAX is a DynamoDB-compatible in-memory cache that requires only minimal application changes because it is API-compatible with DynamoDB, and it reduces eventually consistent read response times from single-digit milliseconds to microseconds, though it does not serve strongly consistent reads out of its cache. The option describing ElastiCache for Redis is wrong because Redis is a separate caching product with its own distinct client API, not compatible with DynamoDB SDK calls, so introducing it in front of DynamoDB would require rewriting the application's data-access code rather than dropping in a compatible client. The option describing raising provisioned read capacity units is wrong because additional RCUs increase how much concurrent read throughput a table can sustain, not the fundamental single-digit-millisecond latency floor of a direct DynamoDB read. The option describing point-in-time recovery is wrong because PITR is a continuous-backup and restore feature for recovering data to earlier points in time, and has no relationship to caching or read latency at all.
Source: AWS DynamoDB documentation: In-memory acceleration with DynamoDB Accelerator (DAX)