THEORY: Distributed Transactions and why you should avoid them (2 Phase Commit , Saga Pattern, TCC, Idempotency etc)

avoid-distributed-transactions.md

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.

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.

[...]

One of the most well-known patterns for distributed transactions is called Saga. The first paper about it was published back in 1987 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;

https://twitter.com/martinkl/status/1349099872897658880?s=46&t=YBcOZUyNB0BvjxHI_HTrKQ

• A Use Case for Transactions: Adapting to Transactional Outbox Pattern Semantics in Spring Cloud Stream Kafka Binder

But as you said, saga is a distribution transaction pattern also. So... what is "avoid distribution transaction"?

• Parallel, Back-pressured Kafka Consumer
  

This article has a very didact explanation of how to implement the different types of delivery semantics, as we can see below:

Offset Manager

Each message in Kafka is associated with an offset - an integer number denoting its position in the current partition. By storing this number, we essentially provide a checkpoint for our consumer. If it fails and comes back, it knows from where to continue. As such, it is vital for implementing various processing guarantees in Kafka:

• For at-most-once, we need to save $offset + 1 before processing $offset. If our consumer fails before successfully process $offset and restarts, it will continue from $offset + 1 and not reprocess $offset.
• For at-least-once, we need to successfully process $offset before saving $offset + 1. If our consumer fails before saving $offset + 1 and restarts, it will continue from and reprocess $offset.
• For exactly-once using an external transactional storage - we need to process $offset and save $offset + 1 within one transaction and roll back if anything goes wrong.

AWS Prescriptive Guidance

• AWS Prescriptive Guidance: Transactional outbox pattern
• AWS Prescriptive Guidance: Saga patterns
  • Saga choreography pattern
  • Saga orchestration pattern

Monkey Exchange - DUAL WRITE: MANTENDO A CONSISTÊNCIA

• @rponte's Gist: Designing fault-tolerant and idempotent APIs with HTTP requests mapped to database's transactions at 1:1 model
• LinkedIn: "Como vocês tem implementado idempotência nas APIs REST das tuas aplicações?"

• Twitter: pergunta do Tomaz sobre impactos do dual-write
  • Twitter: minha resposta
  • Twitter: quando caiu a ficha

Meu RT quando caiu a ficha:

excelente pergunta do @tomazfernandes_ 👏🏻👏🏻

uma solução robusta, tolerante a falhas e barata de implementar que seja retriable, idempotente e abrace consistência eventual eh justamente Outbox Pattern 🤤🤤

viva o ACID dos RDBMS + aquele job em background que roda a cada 1min 🥳

CodeOpinion blog: Listen to yourself pattern: Is it an alternative to the Outbox Pattern?

Tweet by @DominikTornow

The ingredients of failure tolerance & transparency are more basic than you would think:

1⃣ Guarantee retries via persisting the invocation
2⃣ Guarantee correctness of retries via idempotent steps

Outlined in Fault Tolerance via Idempotence