Exams / SAA-C03 / Caching and content delivery / Question 3
SAA-C03 practice question: Caching and content delivery (3 of 3)
Design High-Performing Architectures A free question from our original SAA-C03 practice exam. Try it, then open the answer to see why each option is right or wrong.
A mobile game stores tournament leaderboards in an Amazon DynamoDB table. During live tournaments, the same few thousand items are read millions of times per minute, and the application reads them with strongly consistent GetItem calls. The product owner confirms that leaderboard scores up to a few seconds old are acceptable. The team needs read latency in microseconds and wants the FEWEST changes to the application code. Which solution meets these requirements?
Choose one answer.
- AA. Add a DynamoDB Accelerator (DAX) cluster, swap the DynamoDB client for the DAX client, and keep the strongly consistent reads unchanged.
- BB. Add a DAX cluster, swap the DynamoDB client for the DAX client, and change the leaderboard reads to eventually consistent.
- CC. Add an Amazon ElastiCache cluster, and write cache-aside code that checks the cache first and loads items from DynamoDB on a miss.
- DD. Switch the table to on-demand capacity mode so that it absorbs the read spikes, and keep the strongly consistent GetItem calls unchanged.
Show the answer and explanation
Answer: B
- A. Wrong: DAX is API-compatible with DynamoDB, so the client swap is small. However, DAX passes strongly consistent reads straight through to DynamoDB and does not cache the results, so reads would stay at millisecond latency. Learn more: DAX and DynamoDB consistency models (opens in a new tab)
- B. Right: Correct. DAX serves eventually consistent reads from memory in microseconds and suits a small set of hot items read very often. Because it uses the DynamoDB API, the only code changes are the client and the consistency flag, and slightly stale scores are acceptable. Learn more: In-memory acceleration with DynamoDB Accelerator (DAX) (opens in a new tab)
- C. Wrong: ElastiCache can serve hot items from memory very quickly, so it could meet the latency goal. However, the team would have to write and maintain caching logic, including loading and expiring items, which is more code change than DAX needs. Learn more: Common ElastiCache use cases (opens in a new tab)
- D. Wrong: On-demand capacity removes the need to plan read capacity for spikes, but every read is still served by DynamoDB itself. DynamoDB reads take single-digit milliseconds, so this cannot reach microsecond latency. Learn more: DynamoDB on-demand capacity mode (opens in a new tab)
Explanation
Microsecond reads of hot DynamoDB items with minimal code change point to DAX, but DAX only caches eventually consistent reads; strongly consistent reads go straight to the table. Because slightly stale scores are acceptable, switching the reads to eventually consistent lets DAX serve them. ElastiCache needs custom caching code, and on-demand capacity does not change latency.
Study
Keep practising
Answer questions with a score at the end, or practise just this topic with the explanation after each one. No sign-up needed.