#architecture #orchestration #integration #event-driven

idea

Choreography and orchestration are two ways of sequencing work across different components of a system. Choreography is distributing the responsibility to each of the components to react to an event, while orchestration is centralizing control on an orchestrator giving orders to each of the components.

Orchestrations are good for scenarios where there's a precise workflow, or when the order of sequence of events is important, or with consistency criteria such as auditability or transaction. By nature of having a central component, orchestrations are more prone to failures if that component breaks ; but it also makes errors more visible. It also means that someone is responsible for the workflow and needs to change it if a new component or step wants to insert itself.

Choreography are good when the workflow is in fact more incidental, such as when some of the reactions between components are not just linked to that workflow but to what happened in the previous step (e.g. the workflow to buying something triggers delivery, but also the workflow for replacements, and so the real trigger is the order creation). Choreography by essence are more flexible and increase decoupling. They allow for easier extension. However they are much harder to debug or monitor, and not as good for auditability.

Both can be combined, using orchestrations withing a bounded context, and choreography outside of it[1].

links

references