2

I have been using queues and PubSub patterns for years but never really came across the terminology "event bus". After some googling I didn't really find a clear distinction between "event bus" and "PubSub". Are they the same, just semantic differences?

In the AWS world PubSub seems to imply SNS and event bus seem to imply EventBridge. This makes me think there is a difference.

The difference between SNS and EventBridge is fairly clear. SNS seem to be more towards "fire and forget" while EventBridge has more routing capabilities. SNS also scales on a different level.

In short, what is an event bus? What is event bus vs PubSub?

I came across this link

1 Answer 1

7

For the "publisher/subscriber" pattern, subscriber components have to subscribe (or unsubscribe) to an event publisher. This means the life time of the event publishers is as least as long or longer than any of its subscribers. There are lots of simple scenarios where this is sufficient.

However, when you have a system where you have certain event publishers for a certain type of event, and you may also have subscribers for this type of event, and the life times of publishers and subscribers is completely independent from each other, you need a middle-man component to manage this. That middle-man is called an event-bus.

The event bus has a life time as long as your application or system runs. Subscribers subscribe to the certain type of event at that that bus, and publishers raise the events there.

So, an event bus fullfills a very similar purpose like an event queue, but it does not necessarily provide any FIFO guarantees. For the differences between the latter, I recommend this Stackoverflow question: Message Queue vs Message Bus -- what are the differences?.

7
  • 2
    One important aspect of publish/subscribe is that all potential subscribers need to know and locate all potential publishers, whereas in a bus setup everyone only needs to know the bus and the respective topic. This is significantly less complex (or: pushes the complexity into the bus implementation that you can purchase as middleware).
    – tofro
    Commented Mar 30, 2022 at 23:10
  • 1
    @tofro: that's not necessarily true. In a pub/sub scenario, adding and removing subcriptions can be done by a "third party" as well (and a publisher may only manage a list of callbacks or "abstract subscribers"). Unlike an event bus, this "third party" is only responsible for the setup, but not for the event forwarding itself. The setup component has to know about the publishers and subscribers, the subscribers themselves don't.
    – Doc Brown
    Commented Mar 31, 2022 at 5:38
  • What you describe would, in my opinion, be the first step towards implementing a message bus (the "third party") - but limits are blurry here, admittedly.
    – tofro
    Commented Mar 31, 2022 at 7:32
  • @tofro: I think here in much smaller scales. "Wiring up" the event channels between several components can simply be part of the initialization phase of every software which uses dependency injection. It can be done by builder or factory classes, or a DI container. This all works without an event bus (or message bus, if you prefer that term),
    – Doc Brown
    Commented Mar 31, 2022 at 10:39
  • That's what I'm saying: The first (relatively dumb) message bus implementations did exactly that: Abstracting away the need of providers and subscribers to "know" and locate each other - i.e. concentrating on the wiring. Not much else.
    – tofro
    Commented Mar 31, 2022 at 11:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.