Choreography

In choreography, there is no single orchestrator or central controller dictating the workflow sequence. Instead, each participating service (or agent) independently reacts to events published by other services. This creates a peer-to-peer coordination model where workflow logic is distributed across the system. The overall business process emerges from the collective, reactive behavior of the services.

• Contrast with Orchestration: Unlike orchestration, which uses a central brain (like an orchestration engine), choreography relies on a shared understanding of events and protocols.
• Resilience: The absence of a single point of control can increase system resilience, as the failure of one service does not halt the entire coordinator.

Choreographed systems are fundamentally event-driven. Services communicate exclusively through the production and consumption of asynchronous events over a message bus or event stream. Each service publishes events to signal state changes or completed actions, and other services subscribe to events relevant to their role.

• Loose Coupling: Services are loosely coupled; they only need to know the event schema, not the identity or implementation details of the publisher or other subscribers.
• Common Patterns: This pattern is often implemented using technologies like Apache Kafka, RabbitMQ, AWS EventBridge, or Google Pub/Sub.
• Event Sourcing Compatibility: Choreography aligns naturally with the Event Sourcing pattern, where the event log becomes the system of record.

The business workflow is not codified in a single executable definition (like a DAG in an orchestrator). Instead, it is implicitly defined by the event subscriptions and the internal logic of each service. To understand the full process, one must observe the event flow between all participating components.

• Emergent Behavior: The sequence of steps emerges from the interplay of events and reactions.
• Diagramming Challenge: Documenting the workflow often requires sequence diagrams or event storming sessions to map out the interactions, as there is no central 'source of truth' for the process flow.

Each service in a choreographed system has local autonomy. It is solely responsible for its own domain logic and for deciding how to react to incoming events. This includes managing its own data consistency, error handling, and compensating actions if something fails.

• Saga Pattern Implementation: Choreography is a common way to implement the Saga pattern for distributed transactions. Each service emits events that trigger the next local transaction; if a failure occurs, it may publish a compensating event to trigger rollbacks in previous services.
• Increased Design Complexity: Developers must design each service to be a good citizen in the event ecosystem, considering idempotency, message ordering, and failure scenarios without central oversight.

Observability in choreographed systems is more complex than in orchestrated ones. Because control is distributed, there is no central entity that knows the state of a given business process instance at all times.

• Distributed Tracing Essential: Tools like Jaeger or OpenTelemetry are critical for following a single transaction (distributed tracing) as it flows across service boundaries via events.
• Event Correlation: Debugging requires correlating events by a shared correlation ID to reconstruct the journey of a single request.
• Lack of Global State: Answering questions like "What is the status of order #123?" may require querying multiple services or inspecting the event stream.

Choreography excels in specific scenarios but involves significant trade-offs.

Ideal For:

• Decentralized Domains: Systems where business domains are truly independent and autonomous.
• High Scalability Needs: Event-driven systems can scale consumers horizontally more easily.
• Dynamic Ecosystems: Environments where participants (services) can join or leave the workflow dynamically.

Key Trade-offs:

• Complexity vs. Flexibility: Gains in flexibility and decoupling are offset by increased architectural and debugging complexity.
• Weaker Consistency: Often leads to eventual consistency models, which may not be suitable for all business requirements.
• Duplicated Logic: Similar workflow logic (e.g., "what to do if payment fails") can be duplicated across multiple services.