liemle3893 · December 3, 2022 09:28 · Mar 21, 2022 · Aug 17, 2020 · Oct 23, 2019 · Mar 29, 2019
diff --git a/avoid-distributed-transactions.md b/avoid-distributed-transactions.md
@@ -14,6 +14,6 @@ One of the most well-known patterns for distributed transactions is called Saga.
 There are a couple of different ways to implement a saga transaction, but the two most popular are:
 
    * [**Events/Choreography**](https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part/): When there is no central coordination, each service produces and listen to other service’s events and decides if an action should be taken or not;
-   * **Command/Orchestration**: when a coordinator service is responsible for centralizing the saga’s decision making and sequencing business logic;
+   * [**Command/Orchestration**](https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part-2/): when a coordinator service is responsible for centralizing the saga’s decision making and sequencing business logic;
 
 
diff --git a/avoid-distributed-transactions.md b/avoid-distributed-transactions.md
@@ -13,7 +13,7 @@ One of the most well-known patterns for distributed transactions is called Saga.
 
 There are a couple of different ways to implement a saga transaction, but the two most popular are:
 
-   * **Events/Choreography**: When there is no central coordination, each service produces and listen to other service’s events and decides if an action should be taken or not;
+   * [**Events/Choreography**](https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part/): When there is no central coordination, each service produces and listen to other service’s events and decides if an action should be taken or not;
    * **Command/Orchestration**: when a coordinator service is responsible for centralizing the saga’s decision making and sequencing business logic;
 
 
diff --git a/avoid-distributed-transactions.md b/avoid-distributed-transactions.md
@@ -7,4 +7,13 @@ Distributed Transactions and why you should avoid them
 
 Implementing business transactions that span multiple services is not straightforward. Distributed transactions are best avoided because of the CAP theorem. Moreover, many modern (NoSQL) databases don’t support them. The best solution is to use the [Saga Pattern](https://microservices.io/patterns/data/saga.html).
 
-One of the most well-known patterns for distributed transactions is called Saga. The first paper about it [was published back in 1987](https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf) and has it been a popular solution since then.
+[...]
+
+One of the most well-known patterns for distributed transactions is called Saga. The first paper about it [was published back in 1987](https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf) and has it been a popular solution since then.
+
+There are a couple of different ways to implement a saga transaction, but the two most popular are:
+
+   * **Events/Choreography**: When there is no central coordination, each service produces and listen to other service’s events and decides if an action should be taken or not;
+   * **Command/Orchestration**: when a coordinator service is responsible for centralizing the saga’s decision making and sequencing business logic;
+
+
diff --git a/avoid-distributed-transactions.md b/avoid-distributed-transactions.md
@@ -5,4 +5,6 @@ Distributed Transactions and why you should avoid them
 2. This is a form of using Inter-Process Communication in a synchronized way and this reduces availability;
 3. All participants of the distributed transaction need to be avaiable for a distributed commit, again: reduces availability.
 
-Implementing business transactions that span multiple services is not straightforward. Distributed transactions are best avoided because of the CAP theorem. Moreover, many modern (NoSQL) databases don’t support them. The best solution is to use the [Saga Pattern](https://microservices.io/patterns/data/saga.html).
+Implementing business transactions that span multiple services is not straightforward. Distributed transactions are best avoided because of the CAP theorem. Moreover, many modern (NoSQL) databases don’t support them. The best solution is to use the [Saga Pattern](https://microservices.io/patterns/data/saga.html).
+
+One of the most well-known patterns for distributed transactions is called Saga. The first paper about it [was published back in 1987](https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf) and has it been a popular solution since then.
diff --git a/avoid-distributed-transactions.md b/avoid-distributed-transactions.md
@@ -3,4 +3,6 @@ Distributed Transactions and why you should avoid them
 
 1. Modern technologies won't support it (RabbitMQ, Kafka, etc.);
 2. This is a form of using Inter-Process Communication in a synchronized way and this reduces availability;
-3. All participants of the distributed transaction need to be avaiable for a distributed commit, again: reduces availability.
+3. All participants of the distributed transaction need to be avaiable for a distributed commit, again: reduces availability.
+
+Implementing business transactions that span multiple services is not straightforward. Distributed transactions are best avoided because of the CAP theorem. Moreover, many modern (NoSQL) databases don’t support them. The best solution is to use the [Saga Pattern](https://microservices.io/patterns/data/saga.html).
diff --git a/avoid-distributed-transactions.md b/avoid-distributed-transactions.md
@@ -0,0 +1,6 @@
+Distributed Transactions and why you should avoid them
+------------------------------------------------------
+
+1. Modern technologies won't support it (RabbitMQ, Kafka, etc.);
+2. This is a form of using Inter-Process Communication in a synchronized way and this reduces availability;
+3. All participants of the distributed transaction need to be avaiable for a distributed commit, again: reduces availability.