A retailer runs an order-intake web tier on an EC2 Auto Scaling group that synchronously calls a downstream payment-and-fulfilment worker fleet. During flash sales the worker fleet cannot keep pace, requests time out, and orders are lost when individual workers fail mid-processing. The architecture team must absorb unpredictable spikes, let the worker fleet scale on real backlog, and guarantee no order is dropped if a worker instance terminates, all with the least operational overhead. Which design MOST effectively meets these goals?
- APlace an Amazon SNS topic between the web tier and the workers, subscribe the worker fleet to the topic, and scale the Auto Scaling group on the topic's published-message rate so every order is pushed straight to a worker.
- BPut an Amazon SQS queue between the web tier and the workers, have the workers poll and delete messages only after success, and scale the worker Auto Scaling group on the queue's ApproximateNumberOfMessages depth. Correct
- CKeep the synchronous call but enlarge the worker Auto Scaling group's maximum size and add retries with exponential backoff in the web tier so failed calls are reattempted until a worker eventually accepts the order.
- DStream each order into an Amazon Kinesis Data Stream sized with enough shards for peak, have the workers read from the shards, and scale the Auto Scaling group on the stream's incoming-records metric during sales.
Why A is wrong: SNS is push-based pub/sub with no durable per-consumer buffer, so a spike or a failed worker drops the in-flight message, which violates the no-order-lost requirement even though it decouples the tiers.
Why B is correct: SQS durably buffers every order so spikes are absorbed, a worker that dies before deleting returns the message to the queue after the visibility timeout, and queue depth drives Auto Scaling on real backlog with no servers to manage.
Why C is wrong: Larger maximum capacity and client retries still couple the tiers synchronously, so a sustained spike exhausts retries and timeouts and an order in flight when a worker dies is simply lost.
Why D is wrong: Kinesis suits ordered high-throughput analytics streaming, but it needs shard capacity planning and offset handling, which is more operational overhead than a queue for simple decoupled task processing.