Asynchronous Messaging and Event‑Driven Communication in Microservices

When changes need to be propagated across multiple microservices and their related domain models, asynchronous messaging and event‑driven communication are essential. Because the same model (user, customer, product, account, etc.) can have different meanings in different services or bounded contexts, a method is required to coordinate those changes. The solution is eventual consistency based on asynchronous messaging and event‑driven communication.

Single‑Receiver Messaging

Point‑to‑point messaging delivers a message to exactly one consumer that reads from a channel, ensuring the message is processed only once. Special cases, such as retries in cloud systems, require idempotent handling on the server side.

This pattern is ideal for sending asynchronous commands from one microservice to another, as illustrated in Figure 18.

Once asynchronous messaging is adopted (using commands or events), it should not be mixed with synchronous HTTP communication.

Multi‑Receiver Messaging (Publish/Subscribe)

Using a publish/subscribe mechanism allows a sender’s message to be consumed by multiple subscriber services or external applications, adhering to the open/closed principle and enabling future subscribers without modifying the sender.

Event buses such as Kafka are commonly used for this purpose.

Asynchronous Event‑Driven Communication

Microservices publish integration events when something happens in their domain; other services subscribe to those events and react asynchronously. This pattern often relies on an event bus/Kafka implementation, which can be abstracted behind an interface.

When eventual consistency is driven by integration events, the system must avoid simulated events (e.g., client‑side signals or polling) and ensure that business owners understand and accept eventual consistency.

Multiple services can subscribe to the same event, forming a chain of operations that achieve a distributed business task while maintaining consistency.

Notes on Production‑Grade Messaging Technologies

Message‑bus implementations range from low‑level brokers like RabbitMQ and Azure Service Bus to higher‑level abstractions such as NServiceBus, MassTransit, or Brighter. The choice depends on required features and scalability.

For proof‑of‑concepts, a simple RabbitMQ instance in Docker may suffice; for mission‑critical, highly scalable systems, Azure Service Bus or comparable commercial/open‑source solutions are recommended.

Resilient Publishing to an Event Bus/Kafka

Achieving atomic state updates and resilient event publishing can be done via several techniques:

Transactional queues (e.g., MSMQ) – a traditional approach.

Transaction log mining.

Full event‑sourcing.

Outbox pattern: using a transactional database table as a message queue.

Other considerations include idempotent messaging and duplicate elimination, which are covered later in the guide.

Additional Resources

Event Driven Messaging – https://soapatterns.org/design_patterns/event_driven_messaging

Publish/Subscribe Channel – https://www.enterpriseintegrationpatterns.com/patterns/messaging/PublishSubscribeChannel.html

Udi Dahan. Clarified CQRS – http://udidahan.com/2009/12/09/clarified-cqrs/

Command and Query Responsibility Segregation (CQRS) – https://docs.microsoft.com/azure/architecture/patterns/cqrs

Communicating Between Bounded Contexts – https://docs.microsoft.com/previous-versions/msp-n-p/jj591572(v=pandp.10)

Eventual Consistency – https://en.wikipedia.org/wiki/Eventual_consistency

Jimmy Bogard. Refactoring Towards Resilience – https://jimmybogard.com/refactoring-towards-resilience-evaluating-coupling/