Choreography

Choreography distributes coordination across the services participating in a business process. Each service consumes relevant events, applies its own business rules, updates its local state, and may publish additional events. No single component defines and controls every step of the overall workflow. Events normally describe facts that have already occurred, such as OrderPlaced or PaymentAuthorized, rather than instructions telling another service exactly what to do.

Consider an online store. The order service records an order and publishes OrderPlaced. The payment service reacts by attempting authorization and publishing PaymentAuthorized or PaymentDeclined. The inventory service reacts to PaymentAuthorized by reserving stock and publishing InventoryReserved or InventoryUnavailable. Shipping reacts when its required business conditions are satisfied. Each service owns its local behavior, while the sequence of events connects those behaviors into a larger process.

Cloud implementations commonly use an event bus or publish-subscribe topic to distribute events, with a separate queue for each consuming service when buffering and independent retry are needed. Functions, containers, or other application workers execute the handlers. A shared messaging platform does not make this orchestration: routing messages is different from centrally deciding which business step must run next. Conversely, using asynchronous messages does not automatically make a workflow choreographed if a controller still directs every step.

Reliable implementation requires attention to delivery semantics. Messages can be duplicated, delayed, or received out of order, depending on the transport and configuration. Handlers should use idempotency keys and durable processing records so that retries do not repeat effects such as charging a customer. A transactional outbox can address the failure window between committing a database change and publishing its event by recording both the change and an outgoing event in one local transaction. The publication mechanism still requires retry handling and duplicate-safe consumers.

Choreography typically produces eventual consistency across service boundaries rather than one atomic transaction spanning all participants. If inventory reservation fails after payment authorization, services may react to failure events by releasing reservations or voiding an authorization. These compensating actions represent business recovery, not a database rollback, and can themselves fail or require manual intervention. A choreography-based saga is one application of the pattern, not a synonym for all choreography.

The main benefits are independent deployment, flexible subscription, and reduced direct dependencies between producers and consumers. The costs include less obvious control flow, event-contract dependencies, harder integration testing, and more difficult diagnosis of incomplete processes. Use correlation identifiers, documented event schemas, bounded retries, dead-letter handling, and business-level progress monitoring. For architecture questions, distinguish choreography from orchestration, which places coordination in a controller, and from fanout, which simply distributes one message to multiple recipients. Event-driven architecture is broader than choreography, and neither microservices nor asynchronous messaging requires this coordination pattern.