Billing, paging, and inventory each need the same event when a deployment finishes. The pipeline makes one synchronous call and stops when that single consumer is down. How should the event be routed?
Select an answer to reveal the explanation.
Short Explanation
One phone call that ends when the first person does not answer never reaches the other two. You publish the deployment event to EventBridge and let billing, paging, and inventory each subscribe, so one consumer being down does not swallow the event. A synchronous call to a single system, with or without a sleep, still has that single point of failure.
Full Explanation
The deployment event has three consumers that each need their own copy. EventBridge accepts the event once and delivers it to each subscriber, so billing, paging, and inventory do not depend on one synchronous call. If one target is down, EventBridge can retry that target without the publisher having stopped the whole pipeline on the first failure. Adding a sleep in front of the same synchronous call still talks to one consumer and still stops when that consumer does not answer. Holding the event in one instance's memory makes that instance the only copy. A reboot or a miss by one poller loses the fan-out, and the other systems never had a subscription of their own. Sending the event only to billing and making billing call the other two recreates the same chain: paging and inventory run only if billing reaches them and returns. Caveat: each subscriber needs its own permission to be a target, and a failure of one target should land on that target's retry path rather than on a shared call. Operational check: publish one test event and confirm all three consumers each record it, including when one consumer is stopped.