1
00:00:00,120 --> 00:00:04,260
In this video, we are going to see two types of the implementation.

2
00:00:04,290 --> 00:00:07,350
These are the choreography and the orchestration.

3
00:00:07,680 --> 00:00:08,670
So let me explain.

4
00:00:08,700 --> 00:00:09,480
It's choreography.

5
00:00:09,480 --> 00:00:16,560
Way to set up a then basically choreography provides the coordinate saga with applying public subscribe

6
00:00:16,620 --> 00:00:18,750
principles with choreography.

7
00:00:18,780 --> 00:00:24,840
Each microservice to run its own local transaction and publish event to message broker system and the

8
00:00:24,840 --> 00:00:27,780
trigger to local transactions in other microservices.

9
00:00:28,980 --> 00:00:34,590
This way is good for simple workflows if they don't require too much microservice transaction steps.

10
00:00:34,590 --> 00:00:40,710
But if such a workflow steps increase, then it can be become confusing and hard to manage transactions

11
00:00:40,710 --> 00:00:47,070
between certain microservices because there will be lots of events and it is hard to manage those events

12
00:00:47,070 --> 00:00:48,630
into the transactions.

13
00:00:48,900 --> 00:00:54,900
Also, choreography way decoupled direct dependency of microservices when managing transactions.

14
00:00:55,830 --> 00:00:59,850
So another way of the implementation saga is the orchestration.

15
00:01:00,150 --> 00:01:05,070
Orchestration provides to coordinate signals with a centralized controller microservices.

16
00:01:05,190 --> 00:01:11,700
This centralized controller microservice orchestrate the workflow and invoke to execute local microservice

17
00:01:11,700 --> 00:01:13,530
transactions in sequentially.

18
00:01:14,010 --> 00:01:19,590
So the orchestrator microservice executes the transaction and manage them in a centralized way.

19
00:01:19,590 --> 00:01:25,380
And if one of the step is failed, then executes rollback steps with compensating transaction.

20
00:01:26,130 --> 00:01:30,900
So orchestrating way is good for the complex workflows which include lots of steps.

21
00:01:30,900 --> 00:01:36,990
But this makes a single point of failure with centralized control microservices a need to implementation

22
00:01:36,990 --> 00:01:38,310
of complex steps.

23
00:01:39,400 --> 00:01:44,560
So if you look at the image, the image shows a failed transaction with a single button.

24
00:01:45,070 --> 00:01:50,530
The update inventory operation has failed in the inventory microservices, so when it failed to one

25
00:01:50,530 --> 00:01:55,870
step, the server invokes a set of compensating transactions to roll back the inventory operations,

26
00:01:55,870 --> 00:02:02,200
cancel the payment and the order, and return the data for each microservice back to a consistent state.

27
00:02:02,470 --> 00:02:07,260
So we should careful about when using a pattern in distributed microservice architectures.

28
00:02:07,270 --> 00:02:13,750
If our use case required data consistency across several microservices and required roll back one one

29
00:02:13,750 --> 00:02:14,800
step is failed.

30
00:02:14,800 --> 00:02:16,900
Then we should use saga pattern.