SAP-C02 Practice Question 14: Ordered Fanout SNS FIFO SQS
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 2 · question 4 of 10
An online brokerage is designing a new order-event pipeline. When a customer's order changes state (placed, partially filled, filled, cancelled), the order service publishes an event. Three independent downstream services consume every event: a ledger service, a notification service, and a risk service. Each is owned by a different team and deploys and scales on its own.
The requirements are:
- For any single customer account, each consumer must process that account's events in the exact order they were published. Events for different accounts may be processed in parallel. - A retried publish from the order service must not be processed twice by any consumer. - If one consumer is down for an hour, events must wait for it without slowing the other two. - Adding a fourth consumer later must not require any change to the order service. - The solution must be serverless, with no shards or partitions to size.
Which design meets all of the requirements?
Show answer and explanation
Answer:
SNS FIFO topics fanning out to SQS FIFO queues is the AWS pattern for ordered, deduplicated fan-out. The publisher sets a mandatory message group ID, here the customer account. Ordering is strict within a group, and different groups are delivered in parallel, which gives per-account order with cross-account concurrency. The topic passes the group ID to every subscribed SQS FIFO queue, and messages from every group go to every subscription, so each consumer sees the full stream in order. Message deduplication stops a retried publish from being delivered twice. Each consumer owns its own queue, so a consumer that is down simply builds a backlog in its queue. Adding a consumer means adding a subscription, with no change to the publisher. Nothing needs provisioning in shards.
Option A loses ordering and deduplication. EventBridge does not guarantee event order, and SQS standard queues give at-least-once, best-effort-order delivery. The documentation notes that message groups don't even exist on standard queues.
Option C has the right ordering primitive but no fan-out. Consumers polling one queue *compete* for messages, so each event reaches only one of the three services, not all of them. Coupling three teams to a single queue also means one team's slow processing blocks message groups for everyone.
Option D provides ordering by partition key and independent consumers, but it fails the deduplication constraint. Kinesis Data Streams does not deduplicate producer retries: a retried PutRecord becomes a second record, which each consumer must detect itself. Every consumer also tracks its own checkpoints, and throughput is still expressed in shards, whether you size them (provisioned mode) or Kinesis scales them for you (on-demand mode).
Reference: Amazon SNS message grouping for FIFO topics