How ACID works in a restful micro-service architecture

Question

I'm pretty new at implementing microservice architecture and this question is breaking my mind

How a microservice architecture address transactional mechanism between different end-points calls.

An example is banking services based on a microservice architecture basically, the banking operation is for different calls to different services to complete a transaction, if one of them fails, then there is no way to eliminate the partial process, I do not know if there is any mechanism to solve this problem

create a payment

POST /payments/customer/10/payment/100/

debit money from the account

PUT /customers/10/accounts/20

Send a customer notification

POST /alerts/customers/10

Colonic

Eventual consistency and reconciliation. (In this specific case, the first-class record is probably a Transaction that gets posted to a log, and then consumers take care of updating the downstream records like customer balance and sending alerts.) – Magnum

I find it interesting your point you are referring to resorting to resistance instead of a cancellation case – Colonic

Answer 1

The answer is that your API just doesn't expose any methods that let you create an invalid state.

Each method has to do a complete and valid transaction. Instead of having methods to add and remove money from accounts, for example, you have methods that transfer money between accounts. Any record keeping or notifications that must occur when you transfer money has to be done (or at least queued up) by those methods, too.

Sometimes this requires you to create special "valid" states for transactions that you might otherwise consider to be incomplete. When you're reserving seats in theater, for example, there is a state where your seats are reserved until some time (5 minutes or so) when you haven't paid for them.

Priesthood

I understand you, but what would happen in an esenario where there are different microservices running on different servers each of them interacts with one or more storage systems and at the same time among themselves if one of these microservices fails as the situation should be handled I mean do back to the process already started – Colonic

Generally the same answer -- a microservice should only be able to do complete and valid transactions. Operations that cross multiple microservices can be orchestrated with transactional message queues or exchanging information in a transactional store. Again this creates new "valid states". If service 1 does operation A causes service 2 to do operation B, then in addition to a durable "A and B done" state, you may need an "A done, B durably queued and guaranteed to get done soon" state. – Priesthood