Edition 0 Updated to asp. Net core 0

Asynchronous event-driven communication 
When using asynchronous event-driven communication, a microservice publishes an integration event 
when something happens within its domain and another microservice needs to be aware of it, like a 
price change in a product catalog microservice. Additional microservices subscribe to the events so 
they can receive them asynchronously. When that happens, the receivers might update their own 
domain entities, which can cause more integration events to be published. This publish/subscribe 
system is performed by using an implementation of an event bus. The event bus can be designed as 
an abstraction or interface, with the API that’s needed to subscribe or unsubscribe to events and to 
publish events. The event bus can also have one or more implementations based on any inter-process 
and messaging broker, like a messaging queue or service bus that supports asynchronous 
communication and a publish/subscribe model. 
If a system uses eventual consistency driven by integration events, it
’s recommended that this 
approach is made clear to the end user. The system shouldn’t use an approach that mimics 
integration events, like SignalR or polling systems from the client. The end user and the business 
owner have to explicitly embrace eventual consistency in the system and realize that in many cases 
the business doesn’t have any problem with this approach, as long as it’s explicit. This approach is 
important because users might expect to see some results immediately and this aspect might not 
happen with eventual consistency. 
As noted earlier in the 
Challenges and solutions for distributed data management
 section, you can use 
integration events to imple
ment business tasks that span multiple microservices. Thus, you’ll have 
eventual consistency between those services. An eventually consistent transaction is made up of a 
collection of distributed actions. At each action, the related microservice updates a domain entity and 
publishes another integration event that raises the next action within the same end-to-end business 
task. 
An important point is that you might want to communicate to multiple microservices that are 
subscribed to the same event. To do so, you can use publish/subscribe messaging based on event-
driven communication, as shown in Figure 4-
19. This publish/subscribe mechanism isn’t exclusive to 
the microservice architecture. It’s similar to the way 
Bounded Contexts
 in DDD should communicate, 
or to the way you propagate updates from the write database to the read database in the 
Command 

---

57 
CHAPTER 3 | Architecting container and microservice-based applications 
and Query Responsibility Segregation (CQRS)
 architecture pattern. The goal is to have eventual 
consistency between multiple data sources across your distributed system. 
Figure 4-19. Asynchronous event-driven message communication 
In asynchronous event-driven communication, one microservice publishes events to an event bus and 
many microservices can subscribe to it, to get notified and act on it. Your implementation will 
determine what protocol to use for event-driven, message-based communications. 
AMQP
 can help 
achieve reliable queued communication. 
When you use an event bus, you might want to use an abstraction level (like an event bus interface) 
based on a related implementation in classes with code using the API from a message broker like 
RabbitMQ
 or a service bus like 
Azure Service Bus with Topics
. Alternatively, you might want to use a 
higher-level service bus like 
NServiceBus
, 
MassTransit
, or 
Brighter
 to articulate your event bus and 
publish/subscribe system.