A company hosts its order processing system on AWS. The architecture consists of a frontend and a backend. The frontend includes an Application Load Balancer (ALB) and Amazon EC2 instances in an…

Question

Options

• ACreate an Auto Scaling group and an ALB for the backend. Create a read replica for the RDS
• BCreate an Auto Scaling group and an ALB for the backend. Create an Amazon RDS proxy in front
• CCreate an Auto Scaling group for the backend. Configure the backend EC2 instances to con-
• DCreate an AWS Lambda function to replace the backend EC2 instance. Subscribe the func-tion to

• A
  27% (8)
• B
  10% (3)
• C
  57% (17)
• D
  7% (2)

Explanation

Use SQS FIFO to durably persist orders, guarantee order processing semantics, and decouple producers/consumers. FIFO queues provide "exactly-once processing" with message deduplication and "preserve message order." Visibility timeouts and retries ensure messages are "processed eventually" without being lost; failed messages go to a DLQ for later reprocessing. This pattern aligns with Well-Architected reliability guidance to "queue work to protect against overload and failures" and to ensure "durable, idempotent processing" with retry and backoff. ALB/RDS Proxy/read replicas (A, B) improve availability/connection management but do not guarantee durable handoff or exactly-once processing. SNS (D) is pub/sub and does not provide FIFO semantics in this option, nor a DLQ per subscription for exactly-once. Therefore, frontends write orders to an SQS FIFO queue; backend workers in an Auto Scaling group consume, process idempotently, and use a DLQ for poison messages to meet "no lost orders," "eventual processing," and "exactly-once" requirements.

No community discussion yet for this question.