Event Bus
The infrastructure that enables asynchronous communication between services through events.
What is an Event Bus?
It is the mechanism that allows a service to publish a relevant fact so that other services can react to it without requiring immediate direct calls.
For example:
ms-orderspublishesOrderPlacedms-inventoryconsumes that eventms-notificationsalso consumes it
Why use events?
Because they help you to:
- decouple services in time
- reduce synchronous dependencies
- enable multiple reactions to the same fact
- build distributed processes
Main responsibilities
- Event transport
- Publishing and subscribing
- Retries
- Handling failed messages
- DLQ support
- Support for distributed processes
What it should not be
The event bus should not become a place where the core business logic lives. The reaction logic must reside in the consuming services.
Nor should it be used as an excuse to publish ambiguous or poorly defined events.
Important concepts
Domain event
Represents something meaningful that happened in the business.
Idempotency
Necessary because messages may arrive more than once.
Dead Letter Queue
The place where messages that could not be processed correctly end up.
At-least-once delivery
A common guarantee in many brokers: the message will arrive at least once, but it may be duplicated.
Trade-offs
Benefits
- Decoupling
- Scalability
- More flexible integration
- Distributed processing
Costs
- More operational complexity
- Eventual consistency
- Harder observability
- The need for retries and idempotency
Practical example
An order is created and confirmed.
ms-orders publishes OrderPlaced.
From there:
- inventory decrements stock
- notifications sends a confirmation
- analytics records the event
None of them need to be called directly within the same synchronous flow.
Summary
The Event Bus enables asynchronous communication between services. Its value lies in decoupling and distributing responsibilities, but it demands more discipline around contracts, observability, and idempotency.