After a citizen submits a parks reservation, payment, calendar, and email services each listen for the same domain events and act without a central conductor. Which pattern is this?
Select an answer to reveal the explanation.
Short Explanation
Imagine dancers who each know their cues from the music instead of a conductor waving a baton at every step. Payment, calendar, and email all hear the reservation event and move on their own. That decentralized dance is choreography.
Full Explanation
After a citizen submits a parks reservation, payment, calendar, and email each listening for the same domain events and acting without a central conductor is choreography. In choreography, services subscribe to events and decide their own reactions: payment charges, calendar blocks the field, email sends confirmation. There is no single orchestrator owning every branch. That style fits municipal systems where departments already own their systems of record and only need a shared “reservation submitted” signal rather than a citywide state machine that must be updated whenever email templates change.
Orchestration—where Step Functions alone owns every branch and no service may subscribe to events—is the contrasting pattern; it is wrong here because the scenario explicitly describes independent listeners with no central conductor. A synchronous RPC mesh that forces each service to call the next in a hard-coded chain reintroduces temporal coupling and turns one slow email provider into a failed reservation API. Rewriting all three services into one nightly batch destroys real-time citizen feedback and collapses service ownership.
Exam caveat: choreography and orchestration are both legitimate. Choose choreography when independence and extensibility matter more than a single visible workflow; choose orchestration when order, waits, and help-desk inspectability dominate. Do not assume EventBridge equals choreography exclusively—events can still trigger orchestrated workflows.
Operational check: publish a well-named reservation event with correlation IDs; confirm each consumer is idempotent; add a DLQ per subscriber; and verify that adding a new consumer (for example, a parks analytics sink) requires no change to payment or calendar code.