In real business systems, it is often required to query data owned by two or more services in order to process a client request. For example, a client may want to see all their orders and the payment statuses corresponding to their orders. Before the microservices architecture, this could be implemented with a single join query, but now this is against best practices. To handle a multi-service request, it is required to implement an adapter service that queries both order and payment services, applies all required transformations, and returns an aggregated result to the client. Also, it is quite evident that if two services communicate a lot or highly depend on each other, they may be the right candidates for merging into one service (if such service merging does not harm the domain-driven design). The following diagram depicts this:

The reading strategy is pretty simple, but it is much harder to implement and update a strategy that requires a few services at once. Let's say a client wants to place an order, but it is only possible to have the appropriate inventory balance and payment information validated. Every service has its own database, so within a workflow, two or more microservices and databases are involved in a business transaction. There are a few approaches to tackling such a problem, but the two most popular are distributed transactions and event-driven architecture.