Event Bus Pattern : A Software News Feed

We often see the Event Bus architectural pattern in notification frameworks and Android development.  This approach provides us with a way to have a news feed mechanism across clients and processes. The Event Bus Pattern Defined There are three main players in this event bus pattern.  The players are the sources, the bus, and the listeners.  Within the bus, there are channels.  In this pattern, the listeners subscribe to a channel or channels.  Likewise, the sources post messages to one or more of these.  That allows sources to note something happened.  Likewise, any subscribers will see it.  Note that this is a one-way architecture.  Listeners will not communicate directly with sources.  However, you could have a return bus that listeners are sources for.  Nevertheless, the goal is for the listeners and sources to act without knowledge of each other.  Thus, the items on the channel are "post and forget" messages. Need To Know Basis The problem this pattern solves is when an action is performed or requested, and it needs to be addressed.  However, not right away, and there may be multiple players involved.  We use this approach to queue up those items.  Then, they can be acted on in many ways and many times.  While the peer-to-peer pattern could potentially solve this problem, it is not recommended.  The result can become too complex and place too high a burden on the services involved to maintain those relationships.  Remember that multiple sources can post to a channel, and multiple listeners can be linked to each channel.  This solution allows us to simplify the number of connections in a many-to-many relationship. Challenges This pattern can be over-burdened by listeners or sources.  Likewise, the bus can get filled up.  Therefore, we need to make sure we expire messages on the bus.  Also, we must not allow for too many actors on a channel.  Finally, we need to think about what is put on the bus in terms of size.  While you can have large message sizes, that can cause problems as the network gets filled with too many actors.  The data can be expensive to move around.  Thus, like most patterns, we need to be intentional in our design.  So, we do not put an undue burden on the system.

There are no comments yet.

Please log in to write the first comment.