Even under the best case scenario in MicroServices, something can go wrong. However, if building MicroServices is the selected most viable option then following this patterns will help in running and maintaining the MicroServices.

• Database per service.

In this pattern, every MicroService manages its own data and that means that no other service can access the data directly. Communication or exchange of data can only happen through the owner service. The success of this pattern depends on how well the bounded context of the application is defined.

• Shared Database.

This pattern should be avoided as much as possible. In some instances though, it might be the only viable option to incrementally move to a MicroServices Architecture. This approach is lenient in the sense that multiple services use a shared database. It however, creates a bigger impact service and chances of run-time issues increases.

• API Composition.

This pattern tries to solve the problem of implementing complex queries in a MicroServices Architecture. In this pattern, an API composer invokes other services in the required order. After fetching the results, it performs an in-memory join of the data before returning it to the caller.

This is an inefficient approach due to in-memory joins on potentially larger datasets.

• CQRS and Event sourcing.

This is a pattern designed to solve the problem with API composition pattern, an application listens to domain events from other services and updates a separate query database.This makes it easy to serve complex aggregation queries.

Command and Query Responsibility Segregation (CQRS) can also be combined with Event sourcing where you store the state of the entity(aggregate) as a sequence of Data events.

Of course, this pattern is not that much familiar with the developer's community.

Ultimately, one should learn about the design patterns and their tradeoffs as no single pattern is perfect.

Thank you and see you in the next.

Credits to @ProgressiveCod2 on X(Formerly Twitter).