by Hi everyone! In this article, we will talk about the basic concepts of Event-Driven Architecture (EDA), bringing a base view for future more in-depth posts about the subject. Well, let’s start with some concepts.
So let’s go !! 🚀
In this architecture, we have two main actors, the producers and consumers. Ideally, the producers are responsible for sending a “message” to entities that listen then, waiting for state changes. Sometimes, the architecture can make use of a queue of messages between the producer and consumer, as shown below.
Image 1: Event producer, channels, and consumer structure.
The image shows the event channels working as middleware. This channel (that can be managed with a queue) is responsible for receiving, maintaining (until the message is sent to the receiver), and delivering the message to the producer subscriber. By using a queue to support the message sending, the application can work asynchronously, making it more resilient and allowing responses more quickly to the calling instance, since you can communicate something like “we are processing your solicitation, you can use the system in the meanwhile”.
Even on the basic vision of Event-Driven Applications with queues, you can probably see the power of these concepts mixed. When your request needs a lot of processing that might take some time to be done, you might have to wait until the conclusion of the process, blocking parts of the application that need to wait too. With the EDA architecture, your solicitation can be persisted in the queue, and whenever possible, be processed. That way, the consumer can eventually send you a notification (note that the paper is inverted here, with the consumer turning into the producer of the message). Also, it is intuitive that these benefits are useful when applied in the communication between microservices, for example.
For both cases, the queue can increase the resilience of the system since, if the consumer or the sender turns unavailable, the event sent by the sender can wait until the final destination (you listeners) comes back to work, and then process the solicitation. Another important point is that it is not necessary to maintain a “Point to Point” connection. With this, you can easily add new consumers to listen to the same producer.
Let’s see some visual representations of producers, messages, and your consumers.
Image 2: Illustration of a basic EDA example with a producer 3 consumers.
In the image above, a producer sends a message with an event to the processing queue. The queue will then broadcast the message to all consumers or send it to a specific consumer. You can see that the producer is uncoupled from the consumers, which allows the addition of new ones. An event should only contain the necessary information so the consumer knows what the message is about, as shown in the image below.
Image 3: Messages between producer and consumer in a deeper way.
There, you can see a sequence where a producer makes a request to be processed (1); The consumer receives and sends a message announcing that the processing is started (2) with just basic information; The producer now sends a message with authentication (3), who allows the consumer to know that the message is legitimate and can give sensitive information, like the processing status.
Conclusion
In this article, we had an overview of the Event-Driven Architecture and the message communication between entities. In the next post, we will see a practical implementation of these concepts. If you have any doubts about the subject, let us know. See you :).
References:
Sources:
Featured Image by equaleexperts
Image 1: https://www.scylladb.com/wp-content/uploads/Event-Driven-Architecture-diagram.png
We want to work with you. Check out our "What We Do" section!
