Anomalies due to lack of Isolation in SAGA design pattern As it supports ACD → Part-5

The I in ACID stands for isolation. This isolation property of ACID transactions ensures that outcome of executing multiple transactions concurrently is same as they were executed in some serial order. The database provides the illusion that each ACID transactions has exclusive access to data. Isolation makes it a lot easier to write business logic that executes concurrently.

Challenge with using SAGAs is that they lack isolation property of ACID transactions. That’s because the updates made by each of a saga’s local transactions are immediately visible to other saga once that transaction commits. This behaviour can cause two problem.

  • First is other SAGA can change the data accessed by saga while it is executing.
  • Second issues is that other sagas can read its data before the saga has completed it’s update and consequently can be exposed to inconsistent data.

We can consider SAGA to be ACD.

  • Atomicity → The SAGA implementation ensures that all transactions are executed or all changes are undone by compensating SAGAs.
  • Consistency → Referential integrity within a service is handled by local databases. Referential integrity across services is handled by the services.
  • Durability → Handled by local databases

Overview of Anomalies

Lack of isolation can cause the following three anomalies

  • Lost updates → One saga overwrites without reading changes made by another saga
  • Dirty Reads → A transaction or SAGA reads the updates made by a SAGA that has not yet completed those updates.
  • Fuzzy/non repeatable reads → Two different steps of a SAGA reads same data and gets different results because another saga has made updates.

All three anomalies may happen but first two are more important and let’s discuss them

Lost Updates →

  • The first step of CreateOrder saga create Order
  • While that saga is executing the CancelOrder Saga cancels the Order
  • The final step of Create Order Saga approves the Order

In this scenario the Create Order Saga ignores the update made by the Cancel Order Saga and overwrites it. As a result the Food delivery application will ship an order that customer has cancelled.

Dirty Reads →

A dirty read occurs when one saga reads data that’s in middle of being updated by another saga.

Let’s see one case of Cancel Order saga in any e-commerce service

  • Consumer Service → Increases the available credit ( As order is canceled)
  • Order Service → Change the order status to cancelled
  • Delivery Service → Cancel the delivery

Let’s imagine an inter mixing of Create Order saga and Cancel Order saga. If cancelation of order is triggered but because delivery can’t be cancelled cancel order saga needs to be rolled back and credit needs to be increased again. And in between this Create order saga is triggered.

  • Cancel order Saga → Increase available credit
  • Create Order Saga → Reduce the available credit
  • Cancel Order Saga → A compensating transaction that reduce the credit. .

In this Credit Order Saga does a dirty read. And it enables user to place an order which exceeds it’s credit limit.

These are unacceptable risks to business and must be avoided. In next article we will see how to avoid these anomalies.

Credit → Chris richardson microservices patterns

Software engineer, Leading highly scalable product @scale of million records per day.