544525 (1) [Avatar] Offline
I am currently in the process of digesting the book "Microservices patterns". It introduces me in how to handle this distributed transactionality using the logical concept of sagas as a set of events that occur in the different managed machines as if they were a distributed state machine so that only the next state is advanced when the ACID transaction is resolved locally. and the next event has been inserted in the message broker, only then, the central orchestrator decides the next state or the choreographer. Personally I understand better the figure of the orchestrator than the choreographer, but I think I still have to finish the book, then reread it and then play programming the different components that can appear in a distributed architecture oriented to microservices. It is much more complicated than simply designing different REST components with spring boot, dokerize them and put them behind kubernetes or Marathon / DCOS to climb naturally. An example that has me worried, imagine that you have 3 containers of the same service, with the same logic and each one with an identical local database, the proxy assigns you one of the 3 containers to work, you make the local transaction and the Orchestrator decides the next step, choose another container that contains the following business logic and update the local acid transaction and so on until you arrive at a transaction in a Cn container that fails. What happens here, that you have to rollback in all the previous transactions that have occurred in the different containers, something that is already complex, but imagine that all the transactions have gone well and you have all those containers with those bd coherent with each other, but you have the other instances of the same identical services scaled inconsistent in data with respect to the previous example. What are we doing here? I imagine that it would be necessary for the orchestrator to send the same sequence of commands to the different scaled services so that when the proxy chooses one of these to act, it has the same options of acting correctly because it would have the same data replicated without inconsistencies. I wonder if all distributed transactionality problems are contemplated using Tram and if I should stop worrying about this. Thanks Chris.
ceracm (88) [Avatar] Offline
It is important to distinguish between services (logical, design time) and service instances (runtime processes/containers).

Each service has its own database.

All instance of a service share the same database.