Distributed Transaction

The distributed components of an application will not always be able to complete a task completely isolated. We have already seen how we can use messages to share information between components so that remote components can have the data they need to complete small tasks. Within a simple component, more complex tasks could utilize a transaction to ensure that the entire operation completes atomically.

Local transactions vs. distributed transactions

Let’s talk about local transactions for a moment and why we would want to emulate them as distributed transactions. We use transactions for the atomicity, consistency, isolation, and durability (ACID) guarantees they provide us:

• The atomicity guarantee ensures that the group of queries is treated as a single unit—that is, a single interaction with the database—and that they all either succeed together or fail together.

• The consistency guarantee ensures that the queries transition the state in the database while abiding by all rules, constraints, and triggers that exist in the database.

• The isolation guarantee ensures that no other concurrent interactions with the database will affect this interaction with the database.

• The durability guarantee ensures that once the transaction has been committed, any state changes made by the transaction will survive a system crash.

Within a monolithic application, we can start a local transaction in the database so that all the interactions with the database use a singular view. We can also insert new data that will be atomically written together. Hypothetically, the following diagram shows what the create order process for MallBots would look like without modules and a single database: