Cost-Effective Scalable Ecommerce Architecture with SQS

SAA-C03 By islever Editorial Last updated

Design scalable and loosely coupled architectures.

Short answer

AC Configure SQS to decouple and Auto Scaling to process, while using RDS Proxy to manage database connections efficiently.

Question

A company runs an ecommerce application on AWS. Amazon EC2 instances process purchases and store the purchase details in an Amazon Aurora PostgreSQL DB cluster. Customers are experiencing application timeouts during times of peak usage. A solutions architect needs to rearchitect the application so that the application can scale to meet peak usage demands. Which combination of actions will meet these requirements MOST cost-effectively? (Choose two.)
  1. Configure an Auto Scaling group of new EC2 instances to retry the purchases until the processing is complete. Update the applications to connect to the DB cluster by using Amazon RDS Proxy. Correct Answer
  2. Configure the application to use an Amazon ElastiCache cluster in front of the Aurora PostgreSQL DB cluster.
  3. Update the application to send the purchase requests to an Amazon Simple Queue Service (Amazon SQS) queue. Configure an Auto Scaling group of new EC2 instances that read from the SQS queue. Correct Answer
  4. Configure an AWS Lambda function to retry the ticket purchases until the processing is complete.
  5. Configure an Amazon AP! Gateway REST API with a usage plan.

Key Takeaways

The exam tests the ability to identify asynchronous processing patterns for scalability, often trapping candidates who confuse connection pooling with request buffering.

This question addresses decoupling and scaling an ecommerce application using Amazon SQS and Auto Scaling groups to handle peak traffic cost-effectively.

Common mistake: Many candidates choose B (ElastiCache) because they assume database read latency is the bottleneck, but ElastiCache does not help with write-heavy purchase transactions or front-end timeouts caused by processing delays.

Expert Analysis

Why the Answer Is Correct

Options A and C form a robust, decoupled architecture. Option C uses Amazon SQS to buffer incoming purchase requests, preventing the web tier from being overwhelmed during peak usage. This allows an Auto Scaling group of EC2 instances to process messages at a controlled rate, ensuring reliability and scalability. Option A complements this by addressing database connectivity; RDS Proxy efficiently manages connection pooling, reducing overhead on the Aurora cluster when many EC2 instances connect simultaneously. Together, these actions solve both the application timeout (via buffering/scaling) and the database load issues (via proxying).

Why the Other Options Are Wrong

Option B (ElastiCache) is primarily useful for read-heavy workloads where data changes infrequently. Purchase details are writes, so caching them would require complex invalidation strategies and doesn't address the core issue of handling bursty ingress traffic. Option D (Lambda retries) can be cost-prohibitive at high scales due to per-invocation costs and introduces complexity compared to the straightforward SQS + EC2 pattern. Option E (API Gateway) provides a frontend interface but does not inherently solve the backend processing bottleneck or provide the necessary decoupling for reliable order processing.

Community Comment Notes

Community consensus strongly supports AC, with users noting that SQS is the key to decoupling. One commenter noted that RDS Proxy helps with connection pooling rather than just performance, which aligns with the need to manage DB connections from scaled EC2 instances. Another user pointed out that ElastiCache is better for read issues, whereas this scenario involves transactional writes. Some debate existed regarding whether combining two scaling mechanisms was redundant, but the distinction between input buffering (SQS) and database connection management (RDS Proxy) clarifies their complementary roles.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When asked to scale for peak usage in an ecommerce context, always look for decoupling patterns like SQS first. Then, consider how the backend resources (like databases) are accessed; if many workers connect, RDS Proxy is a strong candidate for optimizing those connections.

Frequently Asked Questions

Why is ElastiCache not suitable for purchase transactions?

ElastiCache is optimized for read-heavy workloads. Purchase transactions involve writes, making cache invalidation complex and inefficient for this use case.

Does RDS Proxy replace the need for SQS?

No. RDS Proxy optimizes database connections, while SQS buffers incoming requests. They solve different bottlenecks: one for DB load, the other for application throughput.

More SAA-C03 FAQ →

Community Votes

AC
57%
BC
43%

57% of anonymous learners picked answer AC. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 13 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 13

  1. sandordini 👍 8
    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.
  2. pujithacg8 👍 4
    when we have SQS in option C why do you have to retry it again I think the answer is B and C
  3. XXXXXlNN 👍 3
    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...
  4. EdricHoang 👍 3
    Combine SQS and auto-scaling EC2: https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html
  5. LeonSauveterre 👍 2
    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.
Show 8 more comments
  1. Cpso 👍 2
    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.
  2. nadeerm 👍 1
    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.
  3. MatAlves 👍 1
    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.
  4. ieffiong 👍 1
    Combining A&C just leads to redundant auto scaling groups especially when you have SQS configured already. The question talks about combination of actions.
  5. tch 👍 1
    application timeouts... not database connection timeout
  6. EllenLiu 👍 1
    why not choose B? C is wired design.
  7. Abdullah_Cloud 👍 5
    i think it's BC
  8. b3b5fdd 👍 1
    B and C!

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

S3 Multi-Region Access Point and Replication Strategy

S-grade

Securing NLB with Security Groups for Minimal Change

S-grade

Most Cost-Effective 7-Year Retention for EBS Snapshots?

S-grade

AWS Forecast vs SageMaker for Time-Series Prediction

S-grade

Practice All SAA-C03 Questions

Access 120 questions with complete answers and detailed explanations.

View Full SAA-C03 Practice Test →

← Back to SAA-C03 Study Guide