Need for Event-Driven Architecture

Microservices architecture presents the problem of distributed data management.

Learn about solving this problem through event-driven architecture.
by Praveen DK � Jan. 10, 18 � Microservices Zone � Analysis
Like (14)
Comment (2)
Save Tweet 10.97k Views
Join the DZone community and get the full member experience. JOIN FOR FREE
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 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.

Image title

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.

Summary
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.