2

Going through the microservices docs and talks, I'm getting the point that using distributed transactions over XA protocol is not a good choice for ensuring consistency of data, because it slows down the system and not all the endpoints support it, e.g REST.

Eventual consistency technique, implemented using retry mechanisms or messaging is suggested.

My questions is, is it possible to use eventual consistency in enterprise applications where consistency of the data in each and every point of time is critical? How to eliminate dirty reads in eventual consistency? or in other words, is it possible to ensure that no 3rd party process is getting the stale data, that were part of not committed "transaction"?

spencergibb
  • 24,471
  • 6
  • 69
  • 75
antonkonovchenko
  • 129
  • 1
  • 9

1 Answers1

0

Well, that's the point of eventual consistency: You cannot guarantee that no process "is getting stale data". Your system will converge to the updated state in a finite amount of time. But you do not know when.

Using a lightweight compensation pattern, you can look at each operation T(i) within a transaction and define a compensating action C(i). You can then guarantee that either

T(1), ..., T(N) or

T(1), ..., T(N), C(N), ..., C(1)

is executed successfully (in a finite amount of time...). That means: Either all operations are successfully executed or all operations will be retracted by executing the corresponding compensations.

As these operations requires coordination between services and do not run in a real transactional, isolated context, of course it is possible to receive stale data that results from a transaction not fully finished or compensated.

mbnx
  • 912
  • 5
  • 11