Yesterday we defined the concept of a queue, explained how SQS implements it and briefly covered when you should (and shouldn’t) use a queue.

Today we will do the same for event buses. All aboard! 🚌

Event Buses

An event bus is a centralized router that takes events and routes them to one or more destinations. Think of it like a regular bus, where people enter the bus and have their own destinations. They exit the bus where and when they please.

There are similarities between an event bus and a message queue. They both receive a message from a producer and expose it to one or more consumer/subscribers via an interface. A key difference is that queues will maintain FIFO (first-in-first-out) ordering of these messages and rely on the consumer to delete messages from the queue. Meanwhile, an event bus will simply fire-and-forget every message to each configured subscriber.

But event buses are implementing a much broader messaging pattern. The pub/sub pattern.

Pub/Sub (The Real Reason You Are Here)

The distinction between pub/sub and event buses is a blurred one. You will find conflicting and opinionated definitions all over the internet. (And here is another one!)

Pub/Sub has two components:

• Publishing: One service simply publishes a message to an interface. By nature, the interface abstracts away all services listening on the other-side.
• Subscribing: One or more services simply subscribe to a particular location in order to receive messages.

All the other bells and whistles are sugar coating the solution. The rule-based subscriptions, the retry logic and the frankenstein of event-driven architecture (Apache Kafka).

A key difference between the above diagram (credit to @boyney123 - Check him out on ServerlessLand) and yesterday’s diagram is that the two consumers are different colours - indicating they are different services. This is the most important distinction to make between queues and pub/sub. If you want the same message to be reliably received by multiple services, you need to use the pub/sub pattern instead of a queue.

EventBridge

As the name suggests, the Amazon EventBridge service is an implementation of event buses (and pub/sub):

• Is the publisher of an event unaware of the subscribers?: Yes
• Does it support a one-to-many producer/subscriber model?: Yes

We discussed in Part 1 of this series what the differences are between events and commands. As the “event” in event bus and Amazon EventBridge implies, these services and patterns are designed for sharing events, not commands. This is because publishers and subscribers are abstracted away from each other. A command should be a set of instructions tailored and targeted from service A to service B. If service A doesn’t know who service B is, how can it tailor and target the command?

SNS

Amazon SNS (Simple Notification Service) is a little harder to digest. What is a “notification”? Is this using pub/sub? Is it an event bus?:

• Is the publisher of an event unaware of the subscribers?: Yes
• Does it support a one-to-many producer/subscriber model?: Yes

So it passes the test of being pub/sub 👍

But SNS is not an event bus, so what is the difference?

When To Use Pub/Sub

The previous two parts of this article series have eluded to when you should be using queues, and when you should be using pub/sub. The following diagram summarizes everything so far:

Async Lambda Invocations

We are now aware that EventBridge buses and SNS topics should be blindly firing their messages towards their targets (after accounting for rules and filters). We also know the publishers should not be aware of the subscribers. So this explains why the Lambda Function integration on both services uses the asynchronous invocation!

Tomorrow: Part 4

What’s your favorite streaming service? 📺

If you answered Netflix, Prime, Disney+ or something similar, then tomorrow is going to ruffle some feathers.

Tomorrow, part 4 of this Level Up: Event-Driven Architecture series will complete the triplet of EDA mechanism definitions, with streams!

Interested In More?

Connect with me on LinkedIn, Twitter and you are welcome to join the #BelieveInServerless Discord Community.

See you tomorrow!