Proposed flow for this scenario

  1. Durable completed operation
  2. Publish identified event
  3. Select subscribers or matching rules
  4. Independent consumer queue
  5. Idempotent consumer effect
  6. Consumer acknowledgement and recovery

This flow describes a design to evaluate. The local experiment explores one stated mechanism. Its scope appears with the controls; the proposed services are not provisioned.

Decision checkpoints

ChoiceFits whenWatch for
SNS topic + a queue per consumerEach subscriber needs independent buffering and retry.Putting independent consumers on one shared competing-consumer queue.
Classic-style event bus rulesEvent patterns determine which bounded targets should receive an event.Assuming an unmatched event will wait in every consumer queue.
Application outboxA committed data change must eventually be published.Assuming publishing cannot repeat after an ambiguous acknowledgement.

Describe the business event precisely

For a synthetic LetX export, ExportCompleted means a usable artifact exists and the authoritative job record identifies it. Include a stable event identity, operation identity, schema version and references to needed data. Avoid distributing entire customer documents when consumers need only the result reference.

Distinguish an event stating a fact from a command asking one worker to act. A consumer should know whether repetition means the same fact or new intent. That distinction shapes idempotency, retention and how support explains an unexpected notification.

Independent work needs independent state

Suppose notification and reporting consumers must both receive each completion event. One SQS queue shared by their workers represents competing delivery, not a guarantee that both independent systems process the event. Use a suitable fan-out arrangement with separate consumer queues when each needs its own acknowledgement and backlog.

A slow reporting consumer should not force the notification consumer to reprocess already completed work. Observe each queue’s age and useful completion separately. Topic publication and queue admission still require the appropriate service/resource permissions.

Name the event-routing model accurately

The local EventBridge console implements a selected classic-style bus with producer events, matching rules and SQS targets. Current AWS documentation distinguishes this from newer subscriber-oriented Custom Event Bus capabilities. The exercise does not implement every bus type, replay mechanism, event source or target.

Create a pattern that matches the synthetic event’s source and detail type, then change one value and inspect the routing trace. A successful publication with no matching rule is different from a matched rule whose target admission is denied. Preserve that distinction in diagnostics.

Publishing and processing are separate retry boundaries

A data update can commit before a publisher reports success. Use a durable outbox or another appropriate coordination design when the application requires eventual event publication. A publisher retry can still repeat the event, so consumers need their own stable effect identity and recovery logic.

Delivery-to-target failure is also different from a consumer receiving a queue message and failing its business action. In real EventBridge, target retry and dead-letter settings apply to delivery. In the local selected subset, inspect the available delivery trace without claiming a complete production retry policy implementation.

For each consumer, record the event identity, expected effect and durable completion condition. Then imagine its acknowledgement is lost. Decide whether the repeated delivery can return the prior outcome or must reconcile an ambiguous external effect. The answer belongs to that consumer; the publisher cannot infer it from a successful event submission.

Fault drill and changed requirement

Question: the notification consumer sends a message but crashes before deleting its queue delivery. Does creating a separate queue for it eliminate a duplicate notification? No. Isolation protects the other consumers; it does not close that consumer’s side-effect acknowledgement gap. Use provider idempotency or reconciliation where available.

Practice SNS-to-SQS fan-out and exact EventBridge rule matching with synthetic content, then receive and leave one message unacknowledged to inspect redelivery. The retry experiment below counts attempt amplification; it does not publish real events or send email. Account for retained work, API operations and failures when evaluating operational cost.

Practice the supported console workflow

SimAWS · ShahriarLabs

Predict it. Test it. Change one thing.

Local educational model. No account or cloud charges. Nothing is deployed to AWS.

Worst-case downstream attempts per initial request: 27.

Nested retries multiply attempts in the worst case. Backoff and jitter change timing; they do not reduce this configured upper bound. Real failures need an end-to-end retry budget.

sim.shahriarlabs.com · Free to explore

Sources and scope

Reviewed against these official references. The model’s supported scope appears alongside its controls.

How we review explanations