Exams / SAA-C03 / Decoupling with queues / Question 2
SAA-C03 practice question: Decoupling with queues (2 of 6)
Design Resilient Architectures A free question from our original SAA-C03 practice exam. Try it, then open the answer to see why each option is right or wrong.
An online retailer's order service must notify three other services, billing, shipping and analytics, each time an order is placed. Each service must receive its own copy of every order and process it at its own pace. The analytics service is sometimes taken offline for maintenance for up to 2 days, and it must not miss any orders while it is down. Which design meets these requirements?
Choose one answer.
- AA. Publish each order to one Amazon SQS standard queue, and have the billing, shipping and analytics services all poll that queue.
- BB. Publish each order to an Amazon SNS topic, and subscribe the HTTPS endpoint of each of the three services directly to the topic.
- CC. Publish each order to an Amazon SNS topic, and subscribe a separate Amazon SQS queue for each service to the topic.
- DD. Have the order service call the API of each of the three services directly, and retry each call until the service responds.
Show the answer and explanation
Answer: C
- A. Wrong: SQS stores messages durably, but in a single queue each message is processed by whichever consumer receives and deletes it first. The three services would compete for orders instead of each getting a copy. A separate queue per service, fed by an SNS topic, gives each service its own copy. Learn more: Amazon SQS standard queues (opens in a new tab)
- B. Wrong: SNS does send a copy to every subscriber, but it pushes messages and only retries an HTTP/S endpoint for a limited time (at most one hour under a custom delivery policy). After that the message is dropped unless a dead-letter queue is set, so a 2-day maintenance window would lose orders. Learn more: Amazon SNS message delivery retries (opens in a new tab)
- C. Right: Correct. This is the SNS-to-SQS fan-out pattern: SNS puts a copy of every order into each subscribed queue, and each service works through its own queue at its own pace. SQS keeps messages for 4 days by default and up to 14 days, so the analytics queue simply builds up while the service is offline. Learn more: Fanout Amazon SNS notifications to Amazon SQS queues (opens in a new tab)
- D. Wrong: Direct calls tightly couple the order service to the others. The order service would have to store and retry two days of orders for analytics itself, and a failure in the order service would lose those pending calls. A topic with a queue per service removes that burden. Learn more: Amazon SQS, Amazon SNS, or Amazon EventBridge? (opens in a new tab)
Explanation
Two needs decide this: every service gets its own copy (fan-out), and a consumer can be offline for days without losing messages (durable buffering). An SNS topic with one SQS queue per service provides both, because each queue holds messages for up to 14 days. A shared queue splits the orders, and HTTPS subscriptions are only retried for a limited time.
Study
Keep practising
Answer questions with a score at the end, or practise just this topic with the explanation after each one. No sign-up needed.