Many developers, architects, and product managers are familiar with the synchronous communication paradigm of REST APIs. In simple terms, you make a request and wait for a response. This is how the web works: you enter a URL (e.g. www.google.com) and it sends a request to the server, which 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, it's 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.
Some examples of this can be:
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 follower details (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 the event payload or message payload.
An Event-Driven Architecture (EDA) is an approach to building applications that uses events to trigger and communicate between services and is common in modern applications built with microservices. An event is a change in state, or an update, like adding a shopping item to a cart on an e-commerce website. Events can also include extra information (often referred to as event payload or message payload) such as user information when they sign up or follower details when they follow you.
Core concepts
In most cases, EDAs are broker-centric, as seen in the diagram below. There are some new concepts in that diagram, 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. Widely used examples of brokers are Apache Kafka, Apache Pulsar, & RabbitMQ, 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 message, and leaves the connection open so the broker can push messages to them.
Message
A message is a piece of information that is sent by publishers to the broker, and received by all interested subscribers. Messages can contain anything and are frequently cataloged as events and commands. As you saw above, events communicate a fact that occurred, while commands are very similar to requests in REST APIs and instruct the subscribers to "do this."
Channels
One detail that might pass unnoticed from the diagram above is the existence of channels. All brokers support communication through multiple channels. The industry doesn't have a common term for them, so you may see them referred to as topics, routing keys, event types, etc. A channel is usually assigned a name or identifier (e.g., user_signed_up) and it is often good practice to send a single type of message through a particular channel.
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.
Conclusion
We've seen what Event-Driven Architecture is, how it works, and explained its components so you now have a better understanding of this concept and why it can be beneficial for your applications! EDA provides an asynchronous communication model which decouples services from one another with minimal overhead and complexity, allowing you to develop more efficient systems that can scale easily as needed with little effort on your part!
Comentários