Saga, Choreography & Orchestration Patterns — Interview Questions

How to use this lesson

Choreography and orchestration are two ways to coordinate a saga, and two general styles of service collaboration. Interviewers want:

• the trade-off in visibility vs coupling;
• a concrete event flow;
• an understanding that compensations are business actions.

Lesson 2 of the microservices chapter covers saga failure handling in depth. This lesson focuses on the patterns themselves.

Q1. What is the Saga pattern for?

Short answer: It manages a business transaction that spans several services, each with its own database, without a global ACID transaction. The transaction is split into local transactions, coordinated by events (choreography) or commands from an orchestrator. Failures trigger compensating actions. Example: placing an order touches Order, Inventory, Payment and Shipping. If Payment fails, the saga releases the stock, cancels the order, and notifies the customer.

Learn it in depth → Saga Pattern

Q2. What is the Choreography pattern for?

Short answer: Services collaborate by publishing and reacting to events, with no central coordinator. Each service decides for itself what to do when it sees an event. Example: a social application publishes PostCreated, and Feed (fan-out to followers), Notification (alert the mentioned users) and Analytics (count it) each react independently. The Post service doesn't know they exist.

Learn it in depth → Event-Driven Architecture Patterns

Q3. What is the Orchestration pattern for?

Short answer: A central orchestrator owns the workflow. It sends commands to the services in a defined sequence, waits for their replies, applies branching, timeouts and retries, and runs compensations on failure. Example: an order-fulfilment orchestrator calls Payment → Inventory → Shipping in order, and knows exactly which step each order is at.

Q4. The Saga pattern: the core idea, in one line.

Short answer: "Replace one distributed ACID transaction with a sequence of local transactions, each publishing the next step, and each paired with a compensating transaction that semantically undoes it." Sagas are ACD, not ACID: they're atomic (through compensation), consistent and durable, but not isolated. Intermediate states are visible, and must be handled with semantic locks, or PENDING states.

Q5. What is the Saga pattern, and how does it manage distributed transactions?

Short answer:

1. Each step is a local transaction in one service. It commits, and emits an event or reply (reliably, through the outbox).
2. The next step is triggered by that event (choreography) or by the orchestrator's next command (orchestration).
3. If a step fails, the compensating transactions of the already-completed steps run, in reverse order.
4. Sagas don't use a global transaction manager. Coordination is by messages. With orchestration, the orchestrator is a central coordinator, but of workflow, not of locks.

Key points to cover:

• Structure your steps as:
  • compensatable steps (which can be undone);
  • a pivot step (the point of no return: once it succeeds, the saga must complete);
  • retriable steps after the pivot (which must eventually succeed; retry them until they do).

Q6. What's the difference between choreography and orchestration in a saga?

Short answer:

Q7. What are compensating transactions, and how are they used in a saga?

Short answer: A compensating transaction is a business operation that semantically reverses a previously committed step, when a later step fails:

• ReserveStock → ReleaseStock;
• AuthorisePayment → VoidAuthorisation (or Refund after capture);
• BookFlight → CancelFlight.

They run in reverse order of completion. Unlike a database rollback, a compensation:

• is a new transaction, which is visible and audited;
• may not restore the exact original state (cancellation fees, an email that was already sent, so send a correction);
• must be idempotent and retryable, since it can't be allowed to fail permanently. Escalate to manual handling if it keeps failing.

Common trap: the source says compensations return the system "to its initial state". Say "to a consistent state". Some effects can only be offset, not erased.

Q8. In what scenarios is the Saga pattern useful?

Short answer:

• Multi-service business processes that must complete all or nothing, logically:
  • order placement (order, inventory, payment, shipping);
  • travel bookings (flight, hotel, car);
  • loan origination (credit check, approval, disbursement);
  • user onboarding across systems.
• Long-running transactions, lasting minutes or days (approvals, human steps), where holding locks is impossible.
• Integrations with external systems that can't join a distributed transaction (payment gateways, airlines).

It's not needed when the invariant lives inside one service. Keep it in one local transaction. And sagas are overkill for pure fire-and-forget side effects (notifications); plain events do.

Q9. What is the Choreography pattern, and how does it work?

Short answer:

1. A service completes a local transaction, and publishes a domain event (through the outbox) to a broker topic.
2. Interested services subscribe (each with its own consumer group), perform their own local transaction, and publish their own events.
3. The workflow emerges from this chain of reactions. Failure events (PaymentFailed) trigger compensations in the services that care.

@KafkaListener(topics = "orders.events", groupId = "payment-service")
void on(OrderCreated e) {
    PaymentResult r = payments.authorize(e.orderId(), e.total(), e.idempotencyKey());
    outbox.publish(r.approved() ? new PaymentCompleted(e.orderId(), r.authId())
                                : new PaymentFailed(e.orderId(), r.reason()));
}

@KafkaListener(topics = "payments.events", groupId = "inventory-service")
void on(PaymentFailed e) { inventory.releaseFor(e.orderId()); }                 // compensation reacts to the failure event

Q10. How does choreography promote loose coupling between microservices?

Short answer:

• Publishers don't know who consumes their events, and consumers don't call publishers. They share only event contracts (schemas).
• New consumers can be added (a fraud check, loyalty points) without changing the publisher.
• Services are decoupled in time: a consumer can be down, and catch up later from the log.
• There's no central component that must change or scale for every workflow.

Key points to cover:

• Coupling moves into event schemas. Version them carefully (a Schema Registry, backward compatibility), because many consumers depend on them.

Q11. What are the pros and cons of event-driven architecture (choreography)?

Short answer:

• Pros:
  • Loose coupling and independent evolution.
  • Scalability: consumers scale independently, and the broker absorbs peaks.
  • Resilience: temporary consumer outages don't fail producers.
  • Easy fan-out to new features.
  • Natural fit for real-time, reactive systems.
  • An event log enables replay and auditing.
• Cons:
  • The overall flow is hard to see: debugging needs distributed tracing, and correlation IDs.
  • Eventual consistency, and user-visible delays.
  • Ordering and duplicates must be handled: idempotency, and keys.
  • Cyclic event chains can form.
  • Error handling is spread across services (DLQs everywhere).
  • Testing end-to-end flows is harder.
  • Schema evolution discipline is required.

Q12. Give an example of how events coordinate services in a choreography model.

Short answer: E-commerce order flow:

1. Order service: creates the order PENDING, and publishes OrderCreated.
2. Payment service (subscribed to OrderCreated): authorises the payment, and publishes PaymentCompleted, or PaymentFailed.
3. Inventory service (subscribed to PaymentCompleted): reserves the stock, and publishes StockReserved, or StockUnavailable.
4. Shipping service (subscribed to StockReserved): creates the shipment, and publishes ShipmentScheduled.
5. Order service listens to all of these, and moves the order along its state machine: PAID → CONFIRMED → SHIPPED, or CANCELLED.
6. The failure path: on StockUnavailable, Payment reacts by refunding or voiding, and Order marks the order CANCELLED. Notification reacts to the terminal events, to email the customer.

Each service reacts only to the events it cares about. None calls another directly.

Q13. What is the Orchestration pattern, and how does it differ from choreography?

Short answer: In orchestration, a dedicated orchestrator (a saga manager, or a workflow engine such as Temporal, Camunda, Netflix Conductor, AWS Step Functions, or a Spring State Machine-based service) explicitly drives the workflow. It sends commands ("ReserveStock for order 42"), and handles replies. In choreography, no one is in charge: services react to events.

• Orchestration gives explicit control and visibility.
• Choreography gives maximum decoupling and autonomy.

Participants in orchestration are still loosely coupled to each other. They're only coupled to the orchestrator's commands.

Q14. How does an orchestrator control the interactions between microservices in a workflow?

Short answer:

1. It persists the saga state (the current step, the data collected, the attempts) durably, so it survives crashes, and resumes where it left off.
2. It sends commands to participants, asynchronously through command topics or queues, or synchronously through APIs, each with a correlation or saga ID and an idempotency key.
3. It awaits the replies or events, and transitions its state machine: next step, branch, or failure.
4. It enforces timeouts (no reply within N minutes means retry or compensate), retries with backoff, and deadlines.
5. It runs the compensations in reverse order on failure, and escalates to humans (task queues) when automation can't resolve.
6. It exposes status: for dashboards, customer queries ("where's my booking?"), and metrics per step.

// Temporal-style workflow: durable, replayable orchestration written as plain code
public class TripBookingWorkflowImpl implements TripBookingWorkflow {
    private final BookingActivities acts = Workflow.newActivityStub(BookingActivities.class,
            ActivityOptions.newBuilder().setStartToCloseTimeout(Duration.ofSeconds(30))
                    .setRetryOptions(RetryOptions.newBuilder().setMaximumAttempts(3).build()).build());

    public TripConfirmation book(TripRequest req) {
        Saga saga = new Saga(new Saga.Options.Builder().build());
        try {
            String flight = acts.bookFlight(req);  saga.addCompensation(acts::cancelFlight, flight);
            String hotel  = acts.bookHotel(req);   saga.addCompensation(acts::cancelHotel, hotel);
            String car    = acts.bookCar(req);     saga.addCompensation(acts::cancelCar, car);
            return new TripConfirmation(flight, hotel, car);
        } catch (ActivityFailure e) {
            saga.compensate();                                   // runs the cancellations in reverse order
            throw e;
        }
    }
}

Q15. What are the advantages and disadvantages of using an orchestrator?

Short answer:

• Advantages:
  • The workflow lives in one explicit place: easy to understand, change, test and audit.
  • Observability: the state of every saga instance can be queried.
  • Built-in timeouts, retries and compensations.
  • It avoids cyclic event dependencies.
  • Participants stay simple (they just handle commands).
  • A good fit for long-running flows and human steps.
• Disadvantages:
  • A central component to run, scale and keep highly available. Engines like Temporal are built for this, but it's still infrastructure.
  • Risk of a "god orchestrator" accumulating business logic that belongs in the services.
  • The orchestrator is coupled to the participants' command APIs.
  • Potential throughput bottleneck.
  • A learning curve for workflow engines.

Keep orchestrators focused on sequencing, and domain rules inside the services.

Q16. Give a real-world use case for the Orchestration pattern.

Short answer: A travel package booking:

1. The orchestrator reserves a flight seat, then a hotel room, then a rental car, then charges the payment (the pivot). Then it issues the tickets and confirmation emails, retrying until they succeed.
2. If the car rental fails, the orchestrator cancels the hotel and the flight, in reverse order, and releases any payment hold.
3. Timeouts handle partner APIs that don't respond.
4. Customer support can see exactly which step each booking is at.

Other good fits:

• Loan or KYC onboarding, with manual review steps.
• Order fulfilment across warehouse, payment and carrier systems.
• Insurance claims processing.
• Media transcoding pipelines.

Follow-up questions this topic invites — and their answers

Q: Can you mix choreography and orchestration? A: Yes, and it's common. Orchestrate the core transactional workflow (order fulfilment) explicitly, and let peripheral reactions (notifications, analytics, loyalty) subscribe to the orchestrator's or services' events, choreographically.

Q: How do you avoid lost messages between saga steps? A: Use the transactional outbox for publishing (the state change and the event are committed together), idempotent handlers keyed by saga or step ID, at-least-once consumption with offsets committed after processing, and timeouts in the orchestrator to detect stuck steps.

Q: How do you handle the lack of isolation in sagas? A: Use semantic locks (a PENDING status that other operations respect), commutative updates, re-reading values before critical decisions ("reread value"), ordering the steps so risky ones come last, and versioning or optimistic locks on the aggregates involved.

Q: Why use a workflow engine instead of hand-coding the orchestrator? A: Engines provide durable state, timers, retries, versioning of running workflows, visibility UIs and scalability out of the box. Hand-rolled orchestrators tend to re-implement these, badly. For one or two simple sagas, a Spring State Machine or a table-driven orchestrator can be enough.