Inspection status updates for one parcel must process in order, but citywide throughput still matters. Which messaging choice best matches that tradeoff?
Select an answer to reveal the explanation.
Short Explanation
One parcel's status changes are like chapters in the same book—they have to stay in order—while other parcels can race ahead. FIFO with a per-parcel MessageGroupId gives that ordering without forcing the whole city into a single file. Standard SQS, unordered SNS, and random S3 prefixes won't protect per-parcel sequence.
Full Explanation
Inspection status updates for one parcel must process in order while citywide throughput still matters—use an Amazon SQS FIFO queue (or an ordered stream) with a MessageGroupId per parcel. FIFO preserves order within each parcel group while different parcels interleave for throughput. That matches code-enforcement reality: parcel A’s “opened → inspected → closed” sequence stays intact without forcing the entire city through one global single-file line.
Using only a standard SQS queue and sorting later in the consumer provides no broker ordering guarantee under concurrent consumers. Publishing unordered SNS notifications and ignoring per-parcel sequence invites out-of-order status flashes in field apps. Writing each update to a different random S3 prefix so listing order defines sequence is not a messaging order primitive and races badly under parallelism.
Exam caveat: FIFO throughput has quotas; choose MessageGroupId granularity wisely—one citywide group serializes everything, while per-parcel grouping is the usual sweet spot. Consumers must still be idempotent because duplicates can occur within the model’s rules.
Operational check: set MessageGroupId to parcel ID; validate in-order processing per parcel under concurrent load; monitor FIFO throughput limits during ticket season; and document deduplication IDs for status update messages.