Answer-first summary for fast verification
Answer: Add an Auto Scaling group for the application that sends meeting invitations. Configure the Auto Scaling group to scale based on the depth of the SQS queue.
## Explanation The issue described is that as the company expands, customers are experiencing delays in receiving meeting invitations. The architecture consists of: 1. A web application on EC2 that accepts appointment requests and publishes them to an SQS queue 2. Another application on EC2 that processes messages from the SQS queue, sends meeting invitations/confirmation emails, and stores meeting info in DynamoDB The bottleneck is likely in the processing of messages from the SQS queue. As the company grows, the number of appointment requests increases, causing the SQS queue depth to grow. The application that processes these messages (sends invitations) is running on EC2 instances that may not be scaling to handle the increased load. **Why option D is correct:** - Adding an Auto Scaling group for the application that sends meeting invitations allows the system to automatically scale the number of EC2 instances based on the depth of the SQS queue - When the queue depth increases (more pending appointment requests), more instances will be launched to process messages faster - When the queue depth decreases, instances can be terminated to save costs - This directly addresses the bottleneck in processing appointment requests and sending invitations **Why other options are incorrect:** - **Option A (DAX cluster):** DAX is a caching layer for DynamoDB that improves read performance. The issue is with sending meeting invitations, not with reading/writing to DynamoDB. - **Option B (API Gateway):** API Gateway would help with managing API traffic to the web application, but the bottleneck is in the downstream processing of appointment requests, not in accepting them. - **Option C (CloudFront):** CloudFront is a CDN that caches content closer to users. This would help with delivering static content faster, but the issue is with processing appointment requests and sending emails, not with delivering web content. The key insight is that the SQS queue acts as a buffer between the appointment acceptance and invitation sending processes. Scaling the invitation-sending application based on queue depth ensures that processing keeps up with incoming requests as the company grows.
Author: LeetQuiz Editorial Team
Ultimate access to all questions.
No comments yet.
The customers of a finance company request appointments with financial advisors by sending text messages. A web application that runs on Amazon EC2 instances accepts the appointment requests. The text messages are published to an Amazon Simple Queue Service (Amazon SQS) queue through the web application. Another application that runs on EC2 instances then sends meeting invitations and meeting confirmation email messages to the customers. After successful scheduling, this application stores the meeting information in an Amazon DynamoDB database.
As the company expands, customers report that their meeting invitations are taking longer to arrive.
What should a solutions architect recommend to resolve this issue?
A
Add a DynamoDB Accelerator (DAX) cluster in front of the DynamoDB database.
B
Add an Amazon API Gateway API in front of the web application that accepts the appointment requests.
C
Add an Amazon CloudFront distribution. Set the origin as the web application that accepts the appointment requests.
D
Add an Auto Scaling group for the application that sends meeting invitations. Configure the Auto Scaling group to scale based on the depth of the SQS queue.