Which method should the solutions architect select?
Configure Amazon DynamoDB Accelerator (DAX) for the new messages table. Update the code to use the DAX endpoint.
Add DynamoDB read replicas to handle the increased read load. Update the application to point to the read endpoint for the read replicas.
Double the number of read capacity units for the new messages table in DynamoDB. Continue to use the existing DynamoDB endpoint.
Add an Amazon ElastiCache for Redis cache to the application stack. Update the application to point to the Redis cache endpoint instead of DynamoDB.
Explanations:
DAX provides in-memory caching for DynamoDB, significantly reducing read latency without major application changes. Users can benefit from faster access to new messages while only requiring minor code updates to use the DAX endpoint.
DynamoDB does not support read replicas. Instead, it uses partitioning for scaling, so this option is not feasible for reducing read latency. Furthermore, directing reads to a replica is not applicable in DynamoDB’s architecture.
Doubling read capacity units can help with read throughput but may not effectively reduce latency for immediate reads, especially under high load. It also does not address potential hot partition issues.
While using ElastiCache for Redis can reduce latency, it requires significant application changes to implement caching logic, which contradicts the requirement for minimal changes. Additionally, synchronization with DynamoDB may introduce complexity.
From my perspective, the answer is:
Configure Amazon DynamoDB Accelerator (DAX) for the new messages table. Update the code to use the DAX endpoint.