Service choreography is a decentralized model for coordinating distributed services, where each component enforces interaction rules locally. Unlike orchestration, there is no central controller and coordination and error handling responsibilities are distributed. It is particularly suited to loosely coupled, domain-specific microservice architectures.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What organizes, connects, or makes decisions possible.
Service choreography coordinates distributed services through shared interaction rules without a central service controlling the whole workflow.
The concept comes from describing distributed business interactions. The W3C WS-CDL specification defines choreography as a global, participant-independent protocol of permitted message and role interactions.
Each participating service knows its role and reacts to messages or events according to the protocol. This supports loose coupling, but distributes overall workflow logic across participants. Versioning, correlation, idempotency, and compensating failures therefore need explicit design.
No central controller drives the whole workflow; participants enforce their local rules.
Roles, messages, and permitted sequences form a shared description of the interaction.
Troubleshooting and change become harder because behavior and responsibility are distributed.
Choreography suits autonomous, event-driven domains where central workflow control is undesirable. It is not simply a synonym for asynchronous communication and differs from orchestration in where workflow control resides.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.