Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 879 discussion

A) uses RDS Proxy which is mainly for connection pooling and availability issues. Proxy is for too many connections(, not for performance: read replicas, caching) B is caching which is designed for solving read-issues. (Here we have timeouts, and connection issues.) C: SQS is good method for decoupling.

i think it's BC

application timeouts... not database connection timeout

Amazon ElastiCache (Option B): ElastiCache can cache frequently accessed data, reducing the load on the Aurora PostgreSQL database. This improves read performance and reduces latency, which helps handle peak traffic more efficiently. Amazon SQS with Auto Scaling (Option C): By sending purchase requests to an SQS queue, the application can decouple the front-end from the back-end processing. An Auto Scaling group of EC2 instances can process messages from the queue, ensuring that the system scales dynamically based on demand. This approach ensures that purchase requests are processed asynchronously, reducing the likelihood of timeouts during peak usage.

Combining A&C just leads to redundant auto scaling groups especially when you have SQS configured already. The question talks about combination of actions.

A - RDS Proxy improves scalability and database connection pooling. B - Only helpful for read-heavy workloads. This question indicates "purchase transactions" (writes), so the main bottleneck is still there. C - SQS allows for better handling of bursts in traffic by queueing requests (which is also true for so many questions before #879). D - Cost-prohibitive at scale due to high invocation rates. And lambda is not suitable for long-running operations like database transactions. E - Irrelevant.

why not choose B? C is wired design.

As a developer choose both A&C is wired? while we use SQS solution to buffer request before handle by EC2 fleet. why we need EC2 in front of SQS from A.? what of thier propose.

BC. Not idea why retry helps in this scenario besides it adds more complexity into the current design and also doesn't resolve the avalibility issue...

B and C!

A - simply pointless. B- You're already using SQS (C), so why using ec2 to "retry the purchase"? They will stay in the queue until the purchase is processed. Otherwise, they will simply return to the queue. C - This decouples the application from direct database calls, allowing the processing of purchase requests to scale independently and manage load more effectively.

when we have SQS in option C why do you have to retry it again I think the answer is B and C

Combine SQS and auto-scaling EC2: https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html