Eventual consistency is more or less the opposite of strict consistency. Lots of you will come from the strict consistency world. A micro service architecture will bring you directly into an eventual consistent world. Why?
​
1) If a micro service changes its state as reaction to a command some other micro services will most probably change their state as well
​
2) A micro service encapsulates its domain. So no other micro service can directly change its data except via a call to its interface methods (command)
​
3) Micro services enforce the use different database formats (schema, document store) etcetera. At the latest here you come into serious problems with a strict consistent approach (no one wants really make use of a DTC)
​
The "glue" between all this are the events which are processed typically via a messaging system for the outside world.
​
Taking this approach you gain massive performance and you loose the classical acid guarantees of the database (you can use transactions within the boundary of the micro service itself but not outside of this)!
​
What is with rollbacks? - You may ask. The following approaches can be taken:
​
1) Compensating transactions. You build rollbacks 'synthetically' in the applications. This increases complexity.
​
2) Transactionless. You pay attention of the order of your commits. First execute the business validations, if succeeded start changing the state of the system. If one does not succeed decide what to do.
​
To 2): You would be surprised - but this is not such an issue as a lot of people think. This is a trade off.
​
​
​
​
​