What is event-driven architecture? What are the advantages of event-driven architecture, and when should I use it? What advantages does it offer, and what price do I pay? In the following, we will look at what constitutes an event-driven architecture and how it differs from others.
At the beginning, synchronous communication
An example of synchronous communication is the web server and the browser. Both participate simultaneously and actively in the communication. The browser sends a request, and the server responds with a page. Another example is the dialogue between two people. While one is talking, the other is sending information to the other. The other person processes the request and responds. The most crucial feature of synchronous communication is the active participation of both parties.
Asynchronous – going to event-driven architecture
With asynchronous communication, the parties do not have to actively participate in the communication at the same time. This is the case, for example, with communication via email. The sender is active and transmits the message to the mail server. At a later time, the recipient finds the mail in his or her mailbox and reads it. The sender and receiver are not active at the same time.
Message Broker – the mediator of asynchronous communication
Sophisticated voices can now claim that asynchronous communication via the email server is actually two synchronous communications. The sender speaks to the server, and the recipient also speaks to the server. First of all, one has to agree with this. However, an important feature of the mail server is that it can be used for a wide variety of conversations. It can therefore do much more than just mediate between the two concrete persons. And the mail server is simply there i.e., both sender and recipient can use it easily.
Disadvantages of synchronous communication
In terms of software architecture, however, synchronous communication has further implications. The sender must know the address of the recipient. This sounds trivial, but it becomes complicated when the receiver is not ready to receive. The busy receiver is still busy answering another request, possibly overloaded. One possibility now is to start other processes. But how does the sender know which processes are ready to receive? Should he send it to a random receiver? And what if the recipient, of all people, is still busy?
Advantages of asynchronous communication
The message broker, e.g., the mail server, takes on a special role. Both sender and recipient actively contact it. The sender transmits a message and receives an acknowledgment of acceptance from the broker. The recipient actively asks for new messages and actively receives them back. This creates a flow control. Each receiver accepts messages at the rate at which it can process them. Scaling occurs through the use of multiple receivers.
The event-driven architecture
Event producers, event routers, and event consumers are at the heart of the
event-driven architecture. Loose coupling enables horizontal scaling and supports the use of microservices. Senders and receivers can be exchanged independently. Varying the receiver instances is key to elastic load balancing. The fault tolerance of this architecture enables resilient and very flexible systems.Of course, this architecture has its price. The message broker or message router must be operated and optimized for the expected load. The entire architecture stands or falls with its function. The number and size of the transmitted messages must be weighed up carefully. Not every broker is scalable. But here, too, scalability is not always necessary. In the end, the cost-benefit ratio must fit.
