A powerful data-modeling methodology that can help us avoid data sharing in microservices, even in very complicated cases, is event sourcing. This is one of the best ways to deal with data modeling in a microservice. An event is an action that happened in the past, and it's not a snapshot of a state. An action itself is equipped with all the information that's necessary to replay it. Data in a database is actually a state gained after performing a stream of events. So, the assumption here is that the same database state can be achieved if the same set of events are processed in the database in the same order. Examples of event sourcing are version control systems that store the current state as differences. The current state is your latest source code, and events are your commits.

Another very interesting fact is that events that have taken place are immutable. An event describes something that happened in the past and thus cannot be undone. For auditing and reporting, it becomes a perfect use case. It brings eventual consistency to the system. So, if you need a strong constant system, event sourcing may be not for you. In simple language, eventual consistency means the system does not ensure being in a consistent state every time. It might give outdated information for some time, but eventually, over a period of time, it will become consistent with its information. That period of time could be 10 seconds or 10 hours; it purely depends on use case and implementation.

If you are moving from a monolithic application to a microservice-based application and have decided to use event sourcing, then there is a very nice tool called Debezium. It streams out the changes happening in your database as events. The microservice component can read this event and utilize it. For more information on Debezium, you can go to https://github.com/debezium.

The success of microservices architecture success lies in the secret of how good one can decompose bigger problems into smaller ones. There is a strong chance we may miss something while breaking down to smaller things from a monolithic to a microservice-based application. So, the golden rule is never do destructive documents.