Need for Event-Driven Architecture
Need for Event-Driven Architecture
Microservices architecture presents the problem of distributed data management. Learn about solving this problem through event-driven architecture.
Join the DZone community and get the full member experience.Join For Free
Record growth in microservices is disrupting the operational landscape. Read the Global Microservices Trends report to learn more.
The Need for Event Driven Architecture and Event Messaging
When developing microservices, we must tackle the problem of distributed data management. Each microservice has its own private database, sometimes a SQL and sometimes a NoSQL database. Developing business transactions that update entities that are owned by multiple services is a challenge, as is implementing queries that retrieve data from multiple services.
Data access becomes much more complex when we move to a microservices architecture. That is because the data owned by each microservice is private to that microservice and can only be accessed via its API. If multiple services access the same data, schema updates require time‑consuming, coordinated updates to all of the services.
Another major issue with microservices is network failure. If any service is down due to a network issue or any other reason, then one service cannot communicate with other and the entire transaction will fail. For example, if Service A is trying to communicate with Service B when B is already down, then the transaction fails.
Event Driven Architecture
For most applications, the way to make microservices work and to manage distributed data successfully is to adopt an event-driven architecture. There are various patterns available, and we are going to concentrate on the very first pattern, called Event Messaging.
Event Driven Architecture is called messaging systems. A message is simply an event or vice versa an event becomes a message. The concept of an event-driven system is that it should cause everything that is interested to be notified of these events that could benefit from knowing about it. Thus, the earliest real-time event-driven systems came up with the notion of publish/subscribe.
Publish/subscribe is another way to describe event-oriented messaging. In the publish/subscribe paradigm, there are publishers and subscribers. A publisher does not need to know anything about the subscribers of the information they are publishing to other than that they are entitled to receive the information. Similarly, the subscriber does not need to know anything about the publisher other than that they are authenticated to be a legitimate publisher.
A pub/sub system should support a mechanism for publishers to find out about new subscribers and subscribers should be able to find the publishers of information immediately upon their availability.
As a subscriber, you would need to know that you can be guaranteed to receive all messages from the publishers in the time sequence they occurred, if desired (reliability and security). All subscribers should be notified of the event as close to the same time as possible.
The Message Broker acts as a key mediator between publisher and subscriber. The purpose of a broker is to take incoming messages from applications and make them available for the subscriber to fetch the messages. The messages will be retained by the broker until it is fetched by the corresponding subscribers. The most popular message brokers are Apache Kafka, Apache ActiveMQ, RabbitMQ (Mozilla Public License), Redis, etc.
In this blog post, we discussed the challenges of distributed data management in microservices and how Event-Driven architecture helps to address these issues using the Event Messaging pattern.
Opinions expressed by DZone contributors are their own.