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;

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