Edition 0 Updated to asp. Net core 0

particular item’s price has changed since they a
dded it to their basket. 
In a hypothetical monolithic version of this application, when the price changes in the products table, 
the catalog subsystem could simply use an ACID transaction to update the current price in the Basket 
table. 
However, in a microservices-based application, the Product and Basket tables are owned by their 
respective microservices. No microservice should ever include tables/storage owned by another 
microservice in its own transactions, not even in direct queries, as shown in Figure 4-9. 

---

34 
CHAPTER 3 | Architecting container and microservice-based 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. 

---

35 
CHAPTER 3 | Architecting container and microservice-based applications