Choreography vs Orchestration Patterns

When microservices need to work together to complete a business process, there are two fundamental coordination patterns. Orchestration uses a central coordinator (like Step Functions) that explicitly commands each service. Choreography has no central coordinator — services listen for events and react independently. Understanding which to use, and when to combine them, is a key architectural skill tested on the SAA-C03 exam.

In orchestration, a central service (the orchestrator) controls the sequence of operations. It calls Service A, waits for the response, then calls Service B, and so on. The orchestrator has full visibility into the process state, handles errors and retries, and can make decisions based on intermediate results. On AWS, Step Functions is the canonical orchestrator — it defines the entire workflow as a state machine and drives each step.

In choreography, services communicate through events without a central coordinator. Service A completes its task and publishes an event (e.g., OrderValidated) to an event bus or topic. Service B listens for OrderValidated events and processes payment, then publishes PaymentCharged. Service C listens for PaymentCharged and ships the order. Each service is autonomous and decoupled — it only knows about the events it consumes and produces, not the other services.

On AWS, Step Functions is the primary orchestration tool. For choreography, the primary tools are Amazon EventBridge (for routing events between services with content-based filtering), Amazon SNS (for simple fan-out), and Amazon SQS (for point-to-point message passing between services). You can mix patterns: use EventBridge for cross-domain choreography between bounded contexts, and Step Functions for orchestrating steps within a single domain.

Orchestration provides centralised visibility — the Step Functions execution history shows exactly where a workflow is, how long each step took, and what failed. Debugging is straightforward. Choreography distributes visibility across multiple services and event buses — tracing a single business transaction requires correlating logs and events across many services. This is why choreography systems rely heavily on correlation IDs and distributed tracing (AWS X-Ray) for end-to-end visibility.

Choreography offers looser coupling — adding a new service that listens to existing events requires no changes to existing services. For example, adding an analytics service that listens for OrderPlaced events is zero-impact to the order or payment service. Orchestration introduces tighter coupling between the orchestrator and all the services it calls — adding a new step requires modifying the state machine definition, though the individual services remain isolated.

Orchestration makes error handling explicit — Step Functions Catch blocks define fallback states for every error type, and the entire workflow history shows the failure context. In choreography, error handling is distributed — each service must handle its own failures and optionally publish a failure event that others can react to. Implementing sagas (compensating transactions to undo work when a step fails) is much more complex in choreography than in orchestration.

Prefer orchestration when: the business process has a clear linear or branching sequence with explicit success/failure outcomes; you need centralised visibility into process status for operations or compliance; error handling involves complex compensation logic; or the workflow is long-running and must survive service restarts. Examples: order fulfilment, patient onboarding, insurance claim processing — all workflows with clear start, end, and audit requirements.

Prefer choreography when: services are owned by different teams who should not be tightly coordinated; the system should be open to extension by new services without modifying existing ones; events represent facts rather than commands (e.g., 'OrderShipped' not 'ShipOrder'); or you want maximum scalability since there is no central bottleneck. Examples: analytics ingestion, notification fanout, audit logging — all cases where multiple independent consumers react to the same event.

Most real-world AWS architectures use both patterns at different levels of granularity. A common hybrid: use EventBridge choreography to decouple bounded contexts (e.g., Order domain emits events; Inventory, Payment, and Shipping domains each respond independently), while within the Payment domain, use Step Functions orchestration to coordinate the internal payment workflow steps (charge, fraud check, authorise, settle). This gives loose inter-domain coupling with internal process clarity.

On the exam, look for these signals. Choreography keywords: 'loosely coupled', 'services react to events', 'teams own independent services', 'fan-out to multiple consumers', 'add new service without changing existing ones'. Orchestration keywords: 'coordinate steps in sequence', 'track workflow state', 'handle partial failures with compensation', 'human approval step', 'long-running process with error handling'. A question describing a central coordinator directing other services is always orchestration.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: orchestration uses a central coordinator (Step Functions) for explicit, visible workflow control, choreography uses events (EventBridge) for loose coupling and extensibility, and most production architectures combine both patterns at different levels of granularity. Next up we explore SAA-C03 exam format and domain weight strategy.