Saga pattern

Managing transactions between microservices

"a software design pattern is a general, reusable solution to a commonly occurring problem within a given context"

(Wikipedia)

The problem

1: Buy goods

Marketplace

Brandon Group

2: Sales Order

3: Purchase Order

4: Confirmation

5: Ship goods

6: Shipment order

7: Ship goods

7: Tracking info

8: Update Order

Customer

Supplier

Logistic partner

The problem (cont.)

"Brandon group" is actually a set of different (micro) services
The state of an order depends on several transactions between different services and external entities
Transactions may not be instant or synchronous

The easy solution

However...

Introducing some key concepts:

Saga

A sequence of steps, each of which is a local transaction in a microservice
The gold saint in the constellation of Gemini

Problem

Compensating transaction

Allows to rollback single steps of the saga

Semantic lock

Prevents unsupported state transitions from happening by using a state machine

2 possible versions

Choreography

Each microservice can emit an event
Each microservice can subscribe to an event

Orchestration

A component of the architecture, the orchestrator, sends commands to the others
Each microservice receives commands from the orchestrator and sends responses

Comparison

Choreography	Orchestration
Loose coupling	Tight coupling
One format for events	Different formats for events
Fully decentralized	Orchestrator as a possible bottleneck
Business process split on different applications	Business process handled almost totally by the orchestrator