Question #1750
A company operates a real-time voting application using Amazon DynamoDB. Users report that their votes are not immediately visible on the leaderboard, though the system handles high throughput without latency issues. The development team confirms that read operations are functioning within expected performance metrics. What should the solutions architect implement to ensure immediate consistency of read operations?
Enable DynamoDB Accelerator (DAX) for caching.
Create a local secondary index (LSI) for the leaderboard queries.
Configure strongly consistent reads for the queries.
Switch to eventually consistent reads for the table.
Explanation
The correct answer is C. Configure strongly consistent reads for the queries.
Why C is correct:
DynamoDB offers two read consistency models:
1. Eventually Consistent Reads (default): Might not reflect the results of a recently completed write, causing delays in visibility.
2. Strongly Consistent Reads: Always reflect all writes that completed before the read, ensuring immediate visibility.
In this scenario, the application uses eventually consistent reads by default, leading to delayed vote visibility. Switching to strongly consistent reads ensures that the leaderboard displays the latest votes immediately after they are written.
Why other options are incorrect:
- A. Enable DynamoDB Accelerator (DAX): DAX caches data but uses eventually consistent reads by default, which does not resolve the consistency issue.
- B. Create a Local Secondary Index (LSI): LSIs improve query flexibility but do not change the read consistency model.
- D. Switch to eventually consistent reads: The problem already stems from eventual consistency; this would worsen the issue.
Key Points:
- Use strongly consistent reads when immediate data visibility is critical.
- DynamoDB's default read model is eventually consistent.
- DAX and LSIs optimize performance but do not enforce strong consistency.
Answer
The correct answer is: C