The data schema Shop supports 163 interface methods. Both, the monolith and the microservice architecture supports all of the service interface methods. Because of this fact, the monolith can be exchanged by the microservice architecture without breaking the API for the user applications such as web or mobile applications. This allows architects to switch from a monolithic architecture in the beginning of the application lifetime to a microservice architecture, if the demand for the abilities of a microservice architecture rise over time. This could be the case, if the amount of users rises more and more. If features like availabilty, scalability or independent deployability of application parts become important. this could be a reason to leave the monolithic architecture to a microservice architecture for the price of a much higher system complexity. Local ACID based transactions should be taken instead of complex global transactions whereever this is also possible in a distributed microservice architecture. The monolith connects to one big global database schema with 26 entities. The microservice architecture consists of 4 microservices where each service connects only to one local database schema. Each of the 26 entities can only be written by one microservice, that is the master for this entity. The entity can also be part of other local schemas in other microservices. But these microservices only get a copy of the master microservice entity via a message broker. The copy of the entity arrives in those microservices with a latency time. Only after this entity copy has been integrated in all other local databases, the whole system is a consistent state. Within the latency time, the system is only eventually consistent. Systems, that depend to a hundred percent on a consistent state, must use the synchrounous calls over the API of the microservices and should not use the copies that arrive via the asynchrounous message broker.
