Chapter 11 Flashcards — Managing Distributed Workflows
flashcards saht distributed-workflows orchestration choreography
What is the core distributed workflow problem that Chapter 11 addresses?
?
In a monolith, the call stack is the workflow state — the runtime thread holds context for the current step. In a distributed system, there is no shared thread, no shared call stack, no shared memory. When a business process spans multiple services, someone must track what step the workflow is on, handle failures at each step, and know when the workflow is complete. This state must be explicitly designed — and every approach involves different trade-offs.
What are the two fundamental communication styles for coordinating distributed workflows?
?
- Orchestration: A central orchestrator (mediator) service explicitly directs each participant service to perform its step, waits for responses, and manages errors and sequencing.
- Choreography: No central coordinator. Each service reacts to events published by other services. The workflow emerges from the interactions — no single service has the full picture.
What is an orchestrator (mediator) in the context of distributed workflows?
?
A dedicated service that controls workflow execution. It: (1) receives the initial workflow trigger, (2) calls each participant service in the correct sequence, (3) waits for responses, (4) tracks workflow state centrally, (5) handles errors by executing compensation (rollback) logic when a step fails, and (6) reports workflow completion. All workflow logic and state live in the orchestrator.
What is the defining advantage of orchestration over choreography?
?
Centralized workflow state visibility. The orchestrator always knows the exact current state of every active workflow instance — which step is complete, which is in progress, and what the results of each completed step were. This makes monitoring, debugging, error handling, and answering “Where is my order?” straightforward. In choreography, this visibility must be deliberately engineered.
What are the three main disadvantages of the orchestration communication style?
?
- Single point of failure: If the orchestrator is unavailable, all in-progress workflows stall — no other service can advance the workflow.
- God service risk: Business logic tends to migrate into the orchestrator over time, making it a service with excessive responsibility that becomes hard to change.
- Scalability bottleneck: All workflow traffic flows through the orchestrator, which must scale proportionally with the number of concurrent workflow instances.
What is choreography in distributed workflows and how does it differ from orchestration?
?
In choreography, there is no central coordinator. Each service subscribes to domain events from other services and knows what to do when it receives those events. Services publish events when they complete their step; downstream services react. The workflow sequence is implicit — embedded in event subscriptions — rather than explicit in an orchestrator’s code. No single service has a complete view of the workflow.
What is the defining disadvantage of choreography over orchestration?
?
Distributed (invisible) workflow state. No single service knows where a specific workflow instance is at any moment. Answering “What step is ticket #4729 at?” requires either reconstructing state from event logs, querying multiple services, or having designed a state tracking mechanism (front controller, stamp coupling, or event sourcing) from the start. Without deliberate design, workflow state is opaque.
What is the “implicit sequencing” problem of choreography?
?
In orchestration, the order of workflow steps is explicit and readable in the orchestrator’s code. In choreography, the sequence is implicit — encoded in which services subscribe to which events. To understand the full workflow, you must trace event subscriptions across all participating services. This makes the workflow harder to reason about, document, test, and change.
What are the three approaches to managing workflow state in a choreography-based system?
?
- Front Controller Pattern: A lightweight entry-point service records workflow start and subscribes to terminal events to record completion. Coarse-grained visibility (start/end) with low infrastructure cost.
- Stamp Coupling: Each event carries an accumulated data envelope containing results from all previous steps. State travels with the events — no shared database. Good for small payloads, bounded workflows.
- Event Sourcing: A dedicated workflow state service subscribes to all events and maintains a complete event log. Full audit trail and queryable state at the cost of significant infrastructure.
What is the Front Controller Pattern for choreography state management?
?
A lightweight first service in the choreography chain receives the initial request and: (1) creates a workflow record with a unique ID in its own database, (2) publishes the first event to start the chain (carrying the workflow ID), (3) subscribes to the terminal event(s) to update the workflow record as complete or failed. It is NOT a full orchestrator — it does not coordinate intermediate steps. It only captures the endpoints of the workflow, providing coarse-grained status: started / in-progress / completed / failed.
What is stamp coupling in the context of distributed workflow choreography?
?
A pattern where each event in the choreography chain carries a data envelope (the “stamp”) that accumulates results from all previous steps. Each service adds its own output fields to the stamp before publishing the next event. Downstream services receive not just what they need for their step but the full accumulated context. The final event in the chain contains the complete workflow record. State requires no shared database — it travels with the events themselves.
What are the trade-offs of stamp coupling for workflow state?
?
Advantages: No shared state database needed; state travels with events; replay is natural since state is in the event stream; each service has full context from all prior steps.
Disadvantages: Events grow larger as workflow progresses (bandwidth and serialization cost); services receive data they do not need; schema changes to early-stage fields ripple through all downstream event schemas; workflow state is not queryable between events — there is no way to ask “what step is workflow 4729 at right now?” without processing all events.
What is event sourcing for workflow state management and when is it appropriate?
?
A dedicated workflow state service subscribes to all events across all participating services. It maintains a complete ordered log of every event for every workflow instance. Current state is reconstructed by replaying the event log. It is appropriate when: (1) full auditability is required (financial, compliance, healthcare), (2) workflows are long-running, (3) complex compensation is needed (you always know what succeeded), or (4) workflow observability and dashboarding are high-priority requirements. The cost is significant infrastructure investment and eventual consistency in the state service.
Compare orchestration and choreography on three key dimensions: coupling, state visibility, and failure model.
?
| Dimension | Orchestration | Choreography |
|---|---|---|
| Coupling | Medium — participants coupled to orchestrator API | Low — only coupled to event schemas |
| State visibility | High — orchestrator holds all state | Low-Medium — distributed or reconstructed |
| Failure model | Single point of failure (orchestrator) | No single point; partial failure possible |
When should you choose orchestration over choreography?
?
Choose orchestration when: (1) the workflow has complex conditional branching or multiple error paths, (2) real-time workflow state visibility is required by business stakeholders, (3) compensation/rollback logic is complex and must be centrally managed, (4) participant services are owned by the same team as the orchestrator, (5) the workflow is long-running and must survive process restarts, or (6) you need deterministic, auditable sequencing with strong consistency guarantees.
When should you choose choreography over orchestration?
?
Choose choreography when: (1) participant services are owned by different teams who need independent deployability, (2) the workflow is simple and linear with few conditional branches, (3) new participants will be added over time without touching existing services, (4) high throughput is needed and a central orchestrator would bottleneck, (5) eventual consistency for workflow state visibility is acceptable, or (6) you want to maximize the decoupling benefits of an event-driven architecture already in use.
How does choreography enable adding new participants to a workflow without modifying existing services?
?
Because services only know about event types (not other services), a new service can join a workflow simply by subscribing to an existing event. For example, if a new “Quality Review” service should trigger after TicketResolved is published, it subscribes to that event — and no existing service needs to change. In orchestration, you would need to update the orchestrator’s code to add the new step. Choreography makes extension open/closed: open for extension, closed for modification.
What is the “god service” risk in orchestration, and how does it manifest?
?
Over time, business logic tends to migrate into the orchestrator because it is the one service that “sees” the whole workflow. What starts as pure coordination (“call A, then B, then C”) gradually accumulates conditional logic: “if the customer is a premium tier, skip step B”; “if assignment fails twice, escalate to a senior expert.” This logic belongs in domain services, not in the orchestrator. The result is a service with too much responsibility that becomes a bottleneck for both changes and deployments — the orchestrator equivalent of a monolithic God class.
What distributed tracing tools are needed for choreography, and why are they non-optional?
?
Distributed tracing tools — Jaeger, Zipkin, OpenTelemetry — are essential in choreography because without them, tracing a specific workflow instance across multiple services and events is impractical. Each event must carry a correlation ID (the workflow ID or trace ID) so that tracing tools can reconstruct the causal chain of events. In orchestration, the orchestrator’s logs are sufficient; in choreography, cross-service correlation is the only way to answer “what happened to workflow instance 4729?”
What is the hybrid pattern combining orchestration and choreography, and when is it appropriate?
?
Use orchestration within a bounded context (where one team controls all participant services) and choreography between bounded contexts (across team boundaries). Example: a core ticket workflow uses an orchestrator (high visibility, complex errors); post-resolution steps (billing, survey) are choreography via a TicketResolved event (those teams are independent). The hybrid gives control where needed and decoupling where independence matters.
How does the Sysops Squad team apply orchestration and choreography to the ticket lifecycle?
?
The team adopts a hybrid: (1) Orchestration for the core workflow (Validation → Assignment → Resolution) — high visibility needed, complex error paths (no-expert-available, escalation), single team owns these services. (2) Choreography for post-resolution steps (Billing, Survey, Completion Notification) — these teams are independent, the steps are simple reactions to TicketResolved, and new post-resolution steps should be addable without touching the core workflow. For choreography state, they use the Front Controller Pattern to record coarse-grained status.
How does workflow communication style choice relate to team topology?
?
Services owned by the same team have low coordination cost — orchestration’s requirement that the orchestrator team knows each participant’s API is manageable. Services owned by different teams have high coordination cost — choreography’s event-contract coupling is much easier to manage across team boundaries than orchestrator API coupling. Conway’s Law applies: the architecture tends to mirror the team structure, and vice versa. Choreography enables greater team autonomy; orchestration concentrates workflow ownership.
What does “workflow state is the hard part” mean in choreography?
?
In orchestration, the orchestrator trivially answers “what step is this workflow on?” In choreography, this question has no trivial answer — the state is distributed across event logs in the message broker and the local state of each participant service. Answering it requires either: (a) accepting coarse-grained visibility (front controller), (b) state traveling with events (stamp coupling, which only surfaces state when an event is processed), or (c) a dedicated state reconstruction service (event sourcing). All three require deliberate design investment. This is why the chapter calls it “the hard part.”
What is the relationship between choreography and the Saga pattern discussed in Chapter 12?
?
Choreography is one implementation style for sagas. A choreography-based saga has no central coordinator — each service publishes a success or failure event, and other services react accordingly (either proceeding or publishing compensating events). An orchestration-based saga has a central saga orchestrator that calls each step and explicitly invokes compensating actions on failure. Chapter 12 develops both in the context of distributed transaction correctness; Chapter 11 lays the groundwork by establishing the orchestration/choreography trade-offs in the simpler (non-transactional) workflow context.
Total Cards: 24
Priority: HIGH
Last Updated: 2026-05-30