Edition 0 Updated to asp. Net core 0

A note about messaging technologies for production systems 
The messaging technologies available for implementing your abstract event bus are at different levels. 
For instance, products like RabbitMQ (a messaging broker transport) and Azure Service Bus sit at a 
lower level than other products like 
NServiceBus
, 
MassTransit
, or 
Brighter
, which can work on top of 
RabbitMQ and Azure Service Bus. Your choice depends on how many rich features at the application 
level and out-of-the-box scalability you need for your application. For implementing just a proof-of-
concept event bus for your development environment, as it was done in the eShopOnContainers 
sample, a simple implementation on top of RabbitMQ running on a Docker container might be 
enough. 
However, for mission-critical and production systems that need hyper-scalability, you might want to 
evaluate Azure Service Bus. For high-level abstractions and features that make the development of 
distributed applications easier, we recommend that you evaluate other commercial and open-source 
service buses, such as 
NServiceBus
, 
MassTransit
, and 
Brighter
. Of course, you can build your own 

---

58 
CHAPTER 3 | Architecting container and microservice-based applications 
service-bus features on top of lower-level technologies like RabbitMQ and Docker. But that plumbing 
work might cost too much for a custom enterprise application. 
Resiliently publishing to the event bus 
A challenge when implementing an event-driven architecture across multiple microservices is how to 
atomically update state in the original microservice while resiliently publishing its related integration 
event into the event bus, somehow based on transactions. The following are a few ways to accomplish 
this functionality, although there could be additional approaches as well. 
•
Using a transactional (DTC-based) queue like MSMQ. (However, this is a legacy approach.) 
•
Using transaction log mining. 
•
Using full 
Event Sourcing
 pattern. 
•
Using the 
Outbox pattern
: a transactional database table as a message queue that will be the 
base for an event-creator component that would create the event and publish it. 
For a more complete description of the challenges in this space, including how messages with 
potentially incorrect data can end up being published, see 
Data platform for mission-critical 
workloads on Azure: Every message must be processed
. 
Additional topics to consider when using asynchronous communication are message idempotence 
and message deduplication. These topics are covered in the sectio">n 
">Implementing event-based 
">communication between microservices (integration events)
"> later in this guide.