How is ACID guaranteed in distributed transactions (based on a muddy article)?

Question

Database

I read an article on transactions between microservices on Habré.
https://habr.com/ru/company/piter/blog/522366/
Well, as usual, a lot has been written about how all these great technologies should work, but in fact, if you think about it, you understand that nothing is real and shouldn't work. The result was an article "we all proved to you that it is guaranteed to work!", but in fact nothing in the article has been proven that it works at all. At least I didn't understand anything.
It says there are 2 options for distributed transactions: 1) two-phase commit and 2) SAGA.

So, about the first one, as I understand it: 2 microservices execute BIGIN TRANSACTION at the command of the coordinator and immediately then UPDATE / INSERT / DELETE in the database, if everything is successful, then they give the coordinator an answer that everything is OK. When the coordinator receives a response from both microservices that everything is OK, then it sends a COMMIT command to both. And the article says that allegedly a commit occurs in both microservices and, all the data is consistent and everything gets hurt. Well, where is the case when COMMIT reached only one of the microservices, and did not reach the other (network break, for example)? Obviously, in this case, the commit will happen only in 1 service, but not in the other, as a result, the data will not be consistent. How is this actually supposed to work? Nothing is described in the article.

The second option - SAGA - there is generally dregs. Allegedly, the services exchange events via the message bus with the coordinator, if both services successfully completed UPDATE / INSERT / DELETE, then they send an OK event, if not, then FAILED, and supposedly if the coordinator received OK from the first service and FAILED from the second, then the coordinator sent ROLLBACK event to the first service. And supposedly again on paper it turns out that everything is perfect, clear, guaranteed! YES why all of a sudden? And if your ROLLBACK event did not reach the bus (network break or something), then what?

I understand how transactions work inside one database, I read about the algorithm in the transaction mechanism, so I understand that this is realizable inside one database. And when I try to understand how it is implemented at the level of several distributed databases, I get to similar articles in which there is only dregs under the guise of scientific literature.

In general, a little bombanulo. But maybe someone will still explain in a normal way the principle of how ACID is guaranteed in distributed transactions?

Answer 1

It is possible to guarantee ACID only with limitations. In this case, what you are talking about is called "a victim of resistance to partitioning (that is, a failure in the communication system between nodes)". See the CAP theorem

Answer 2

The same questions are in the comments to the article, and the answers to them are also given there: an a priori statement is made that the probability that the bus will fail is significantly lower than the probability that the transaction will be repulsed on the side of one of the DBMS.

Answer 3

So, judging by the comments in this topic, a two-phase commit or SAGA is, in principle, NOT TRANSACTIONS, i.e. there is no actual transactionality there? So, any system of related microservices is a priori not a reliable system and data loss is always possible? In any banking system, if it is microservice (and now all are), inconsistent data is possible, and as a result, the loss of money from customer accounts due to errors?
As for the fact that a network failure is much less likely (and not only on the network, but somewhere even on the server) than in the DBMS, I don’t really agree, in general, there is often a situation even when you go to the site in the browser, and the browser gives some kind of network error, but as soon as you reload the page, the site loads.

Answer 4

inside one database it is realizable.

Strictly speaking, there are no guarantees either. The disk subsystem can fail at any time. In addition, now drives are often networked ...

So, judging by the comments in this topic, a two-phase commit or SAGA is, in principle, NOT TRANSACTIONS, i.e. there is no actual transactionality there?

I won’t speak for SAGA, but two-phase commit, in addition to what is described in the article, should, according to the idea, just like a stand-alone DBMS does, keep a log of logs before starting a transaction. Possibly distributed. It is the log (or rather, its processing) that provides recovery after hardware (including network failures). The two-phase commit itself guarantees only that inconsistent data will not be written (and read before writing).

Does this mean that any system of related microservices is not a priori a reliable system and data loss is always possible?

Yes. The world is not perfect. The more links in the chain of failure, the higher the probability of this very failure. As everyone knows, this probability is equal to the product of the probabilities of each element. That is, when designing a microservice architecture, you can calculate the failure probabilities of all its components, taking as a basis the probability of hardware failures or, if there is, then more precisely failure statistics. And make a decision, can you do this or is it better to leave the monolith in this particular place. Another thing is that so far I see for the most part "hasty" microservice hacks who make them on the principle "because it's fashionable". But as I believe, there are still people in the banks who understand what this threatens, otherwise we would stop using ATMs, because no one wants to prove to the bank every day,