Well, Saga actually provides guarantee of ACD. You can checkout Chris Richardson's latest talk of saga[1] for details. In the original saga paper[2], it mentions that
> At the outer level full atomicity is not provided. That is, sagas may view > the partial results of other sagas. > According to the ACID definition[3], it shows saga does not provide isolation guarantee instead of atomicity as all sub transactions within a global transaction is either done or compensated. For each global transaction, it will have both SagaStartedEvent and SagaEndedEvent while for each sub transaction, it will have TxStartedEvent and either TxEndedEvent or TxCompensatedEvent. If the global transaction succeeds, saga guarantees that all sub transactions will have both TxStartedEvent and TxEndedEvent. If the global transaction fails, saga guarantees that all completed sub transactions are compensated and hence have all of TxStartedEvent, TxEndedEvent, TxCompensatedEvent. In this way, we can guarantee the consistency. Besides, the implementation of saga coordinator is stateless, all saga event logs are stored in persistent storage. In this way, we can guarantee the durability. BTW, we have refactored the saga lately. The architecture in the blog you saw is outdated. You can checkout its latest implementation from [4]. If you have any questions or advice for our new architecture, welcome to point them out. [1] https://www.infoq.com/presentations/saga-microservices [2] https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf [3] https://en.wikipedia.org/wiki/ACID [4] https://github.com/apache/incubator-servicecomb-saga Best Regards! Eric Lee 2018-03-09 15:59 GMT+08:00 Daniel Qian <chanjars...@gmail.com>: > Hello guys: > > I read the amazing blog "Eventual Data Consistency Solution in ServiceComb > - part 2" and I'm kind of confused about these two statements: > > > Saga does not provide ACID guarantee, because atomicity and isolation are > not satisfied .... > > > With durable saga log, saga guarantees consistency and durability > > I guess the first statement is talking about how so called "Transaction" > behaves in **Saga pattern**. > > And the second statement is talking about the implementation of Saga's > state store. But that's a little strange to say "Saga provides C and D > because it's state store provides C and D". > > I think Saga pattern actually does not guarantee either of A, C, I or D. Am > I right? > > > -- > > > > Daniel Qian >
