liveBook · Manning

Saga

As explained in gRPC Microservices in Go

A saga is a distributed transaction pattern that coordinates a sequence of local transactions and uses compensating transactions when a step fails.

A saga coordinates a sequence of local transactions across services that own separate data stores. Each step updates one service; a later step can be triggered by a message or directed by an orchestrator. This provides a way to manage consistency when one transaction cannot cover the whole workflow. Two-phase commit is another approach to distributed transactions. section 2.3.2

Choose how the steps are coordinated:

  • Choreography: each service commits its local transaction and publishes an event that triggers the next service. A command channel targets the next service and can specify a reply channel, but its publisher must know that service’s location. With pub/sub, interested services consume domain events. section 2.3.3
  • Orchestration: an orchestrator directs participants through command channels or request/response calls and chooses the next step from each response. A request/response design requires services to know the addresses needed to connect. section 2.3.4

Creating an order

In a choreographed flow, Order Service creates an order as PENDING and publishes an order-created event. Payment Service attempts the charge and reports success or failure. A failure marks the order FAILED; a successful payment allows Shipping Service to proceed. Shipping’s result ultimately marks the order FAILED or SUCCESS. In an orchestrated flow, a shipping failure instead prompts compensating transactions in reverse order: refund the payment, then cancel the order. section 2.3.3 section 2.3.4

Plan how the client learns the outcome of a saga that does not finish immediately. The service can return the result on completion, return an identifier for polling, or send the result over a WebSocket connection. section 2.3.3

Figure 2.5 An orchestrator for an order creation creates an order and payment process, and the Shipping service starts to complete the order flow. It runs a compensation transaction in case of failure, and this is executed from the bottom up.

The order-flow diagram shows the orchestrator’s steps and the reverse compensation path after failure. section 2.3.4

How gRPC Microservices in Go covers it

How deep it goes
Explains choreography, orchestration, client completion options, and reverse compensation through workflows rather than implementation code.
Examples
Traces an order through payment and shipping, including failure status changes, refunds, and cancellation.
What it assumes
Assumes familiarity with services and local transactions while introducing the two saga coordination patterns.
What you can do after
Apply it via event channels or an orchestrator to coordinate order, payment, and shipping steps and compensate after failure.
How it connects
Links sagas to two-phase commit, pub/sub, command channels, request/response communication, and compensating transactions.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of gRPC Microservices in Go. The section links point to the parts of the book it draws on.