Event-driven architectures

Found an error? Have a suggestion?Edit this page on Github

Many developers, architects, and product managers have used REST APIs and are familiar with the synchronous communication paradigm. You make a request and wait for the response. This is exactly how the world wide web works. You enter a URL e.g., www.google.com in the browser's address bar and it sends a request to the server. Following, the server sends the response with the website content. The web is the greatest implementation of a REST API.

However, there are certain situations where you don't really need a response from the server. In most cases its only important to have some confirmation that the request was received. This is also called "fire and forget", and it's very useful when you just want to communicate or inform that "something happened." You're not requesting or asking for anything, thus you don't need a response. Examples of this are:

  • A user just signed up.
  • You have a new follower.
  • Your fridge is almost empty.

Along with the event, you may also want to send extra information. For instance:

  • A user just signed up: here's the user information e.g., name, email, age, etc.
  • You have a new follower: here are the details of the follower e.g., username, name, picture, etc.
  • Your fridge is almost empty: here's the percentage of "emptiness" or available volume e.g. 23%

This extra information is often referred to as event payload or message payload.

Core concepts

In most cases, Event-Driven Architectures (EDAs) are broker-centric, as in the diagram above. There are some new concepts in it, so let's go through them now.

Message broker

A message broker (or "broker") is a piece of infrastructure in charge of receiving messages and delivering them to those who have shown interest. They often store messages until they are delivered, which makes EDAs very resilient to failures. Examples of brokers are RabbitMQ, Apache Kafka, Solace, etc.

Publisher/Subscriber

A publisher (a.k.a. producer) is an application that sends messages to the broker.

A subscriber (a.k.a. consumer) is an application that connects to the broker, manifests an interest in a certain type of messages, and leaves the connection open so the broker can push messages to them.

Message

A message is a piece of information that's sent by the publishers to the broker, and received by all the interested subscribers. The content of the message can be anything, and they are frequently catalogued as events and commands. As you saw above, events communicate a fact that occurred. On the other hand, commands are very much like requests in REST APIs: They tell the subscribers "do this."

To be precise, events and commands share the same structure, but differ conceptually.

Channels

One detail that might pass unnoticed from the diagram above is the existence of channels. All the brokers support communication through multiple channels. The industry doesn't have a common term though so you may find them as topics, routing keys, event types, and probably other ones I'm missing.

They're usually assigned a name or identifier e.g., user_signed_up and it's often good practice to send a single type of message through them. Think about TV or radio channels: the BBC only broadcasts its information through an assigned channel. If the broadcasters (publishers) didn't respect that rule you (the subscriber) would only see and hear interferences.

Why "event-driven" and not "message-driven"?

You will find both used interchangeably, although they are not exactly the same. You will even find "message-based" and "event-based". In practice, chances are they all refer to the same thing.

Theoretically, "message-driven" is the most generic term, meaning you may use events and commands, while event-driven means that it's purely about events. However, that's not always the case, as Martin Fowler explains in his talk "the many meanings of event-driven architecture":

Conclusion

We've seen what an event-driven architecture is, how it works, and explained its components. AsyncAPI defines and documents each of these components. We'll go through it during the rest of this guide but, before you continue, please choose what's your next step: