5 Distributed transactions

 

This chapter covers

  • Creating data consistency across multiple services
  • Using event sourcing for scalability, availability, lower cost, and consistency
  • Writing a change to multiple services with Change Data Capture (CDC)
  • Doing transactions with choreography vs. orchestration

In a system, a unit of work may involve writing data to multiple services. Each write to each service is a separate request/event. Any write may fail; the causes may include bugs or host or network outages. This may cause data inconsistency across the services. For example, if a customer bought a tour package consisting of both an air ticket and a hotel room, the system may need to write to a ticket service, a room reservation service, and a payments service. If any write fails, the system will be in an inconsistent state. Another example is a messaging system that sends messages to recipients and logs to a database that messages have been sent. If a message is successfully sent to a recipient’s device, but the write to the database fails, it will appear that the message has not been delivered.

A transaction is a way to group several reads and writes into a logical unit to maintain data consistency across services. They execute atomically, as a single operation, and the entire transaction either succeeds (commit) or fails (abort, rollback). A transaction has ACID properties, though the understanding of ACID concepts differs between databases, so the implementations also differ.

5.1 Event Driven Architecture (EDA)

5.2 Event sourcing

5.3 Change Data Capture (CDC)

5.4 Comparison of event sourcing and CDC

5.5 Transaction supervisor

5.6 Saga

5.6.1 Choreography

5.6.2 Orchestration

5.6.3 Comparison

5.7 Other transaction types

5.8 Further reading

Summary