Send each message to the right consumers

Start with one business fact, such as “order 482 was accepted.” Ask who owns it, which consumers need a copy, whether the producer may wait, how long an outage may last, and whether old records must be replayed.

A synchronous call fits when the caller needs an immediate result and accepts the dependency's latency and availability. An asynchronous handoff fits when work may finish later and the producer should continue while consumers recover.

Amazon SQS stores work for competing consumers. One message is processed by one of the workers, not copied to every business function. Standard queues use at-least-once delivery and best-effort ordering.

Visibility timeout is a processing lease. A worker receives a message, performs the work, and deletes the message only after success. If it crashes first, the message becomes visible for retry.

Define maximum backlog age, duplicate tolerance, retention, ordering scope, and poison-message handling before choosing a broker. “Use events” is not yet an architecture.

Use one SQS queue when several equivalent workers compete to complete one job. This smooths bursts and lets another worker retry when a lease expires.

Use SNS or EventBridge to fan one event out when fulfillment, analytics, and email each need their own copy. Give each consumer its own SQS queue so one outage grows only that consumer's backlog.

EventBridge routes events from many sources to selected targets using rules. It does not replace a durable competing-consumer queue when the target needs backlog ownership.

Use Kinesis Data Streams when independent consumers must replay retained records and ordering within a partition key matters. A hot partition or one FIFO message group can serialize throughput, so choose the ordering key deliberately.

The products may be combined because they own different jobs. EventBridge can decide which business functions receive an event, while separate SQS queues buffer each function's work.

Test the shape. Pause analytics and verify its queue age grows while fulfillment continues. If one shared queue causes either analytics or fulfillment—not both—to receive an order, the design chose competition where fanout was required.

At-least-once delivery means the same operation can arrive again. Put a stable operation ID on every irreversible side effect and store the completed result so a retry can return it instead of repeating the action.

Consider a worker that charges a card and crashes before deleting its SQS message. The queue cannot know the charge completed. On retry, the worker must look up the order operation and discover that the charge already exists.

Set visibility timeout longer than ordinary processing or extend it safely. Use bounded retries for transient errors. Move repeatedly failing input to a dead-letter queue, or DLQ, for investigation. A DLQ is quarantine, not successful completion.

Keep contracts loose but explicit. Version schemas, tolerate additive fields, restrict publishers and consumers, encrypt messages, and avoid placing secrets or full payment data in operator-facing dead-letter payloads.

Monitor accepted events, backlog count and age, retries, duplicate suppression, failed subscribers, and drain time. Eight hours of retention is useful only when the recovered consumer can drain the backlog before expiry and before the business deadline.

For the order scenario, fan out to three queues. An analytics outage should not stop checkout or fulfillment, and duplicate injection should produce one fulfillment state transition for the same order ID.