An event bus is a messaging channel where an event producer sends an event, and any number of event listeners can receive the event and act on it. The important distinction between an event bus and basic event handling is that with an event bus the event producer and recipient don’t know about each other, they only know about the message channel. This is a popular pattern that allows you to develop an architecture where components are loosely coupled. It works similar to IRC (Inter-Relay Chat), where you send a message to the channel, and everyone may respond if they wish to.
Message Bus a.k.a. Event Bus
If your application requires a number of modules that need to communicate with each other in various ways, this architecture is a sure bet. It is endlessly flexible: you can add and remove modules at run-time, communicate directly or broadcast messages. It is completely free.
- Process monitoring
- Trading Systems
- Software development environments
When should you use it?
Use it when your application can be factored in functionally separable modules that are capable of communicating through simple messages.
How does it work?
Modules may be added and removed at any time.
When a module wishes to communicate with another module or other modules, it places a message on the Event Bus. The Event Bus takes care of delivering the message to the recipients.
Event Bus architecture
There are several types of communication that may occur on the Event Bus:
- Publish-Subscribe: Modules may subscribe to certain message types. Whenever a module publishes a message to the bus, it will be delivered to all modules that subscribed to its message type.
- Broadcast: The message will be delivered to all (other) modules.
- Point-to-point: The message has one and only one recipient.
The sending module normally doesn’t care when the other modules receive and process the message. If the time of processing is important, the message may be sent immediately. It corresponds to calling the function in receiving modules directly, with the difference that the modules are still decoupled.
- If the modules share large amounts of data, it may not be a good idea to pump these over the bus all the time. If you choose to share the data between the modules, make sure no synchronization issues occur.
Common implementation techniques
- Relates to the Observer Design Pattern, with added functionality.