NET-Microservices-Architecture-for-Containerized-NET-Applications

Figure 4-9. A microservice can’t directly access a table in another microservice
The Catalog microservice shouldn’t update the Basket table directly, because the Basket table is
owned by the Basket microservice. To make an update to the Basket microservice, the Catalog
microservice should use eventual consistency probably based on asynchronous communication such
as integration events (message and event-based communication). This is how the eShopOnContainers
reference application performs this type of consistency across microservices.
As stated by the CAP theorem, you need to choose between availability and ACID strong consistency.
Most microservice-based scenarios demand availability and high scalability as opposed to strong
consistency. Mission-critical applications must remain up and running, and developers can work
around strong consistency by using techniques for working with weak or eventual consistency. This is
the approach taken by most microservice-based architectures.
Moreover, ACID-style or two-phase commit transactions are not just against microservices principles;
most NoSQL databases (like Azure Cosmos DB, MongoDB, etc.) do not support two-phase commit
transactions, typical in distributed databases scenarios. However, maintaining data consistency across
services and databases is essential. This challenge is also related to the question of how to propagate
changes across multiple microservices when certain data needs to be redundant—for example, when
you need to have the product’s name or description in the Catalog microservice and the Basket
microservice.
A good solution for this problem is to use eventual consistency between microservices articulated
through event-driven communication and a publish-and-subscribe system. These topics are covered
in the section Asynchronous event-driven communication later in this guide.
36 CHAPTER 4 | Architecting container and microservice-based applications