Have you ever developed an event-driven application or heard about this architectural approach? You might be surprised to learn that you may be using it even if you've never heard of it! This post series will explain what EDA architecture is, why it was created, what its components are, and how it is used in the Java ecosystem. In part one, you'll learn the core concepts of EDA. In part two, you'll walk through the implementation of a simple EDA project in Java.
First, we need to understand what an event is in the context of a system. Every change of information, even the tiniest change, can be considered an event. For example, the change of a user address can be considered an event.
Changing an address - let's say in a mobile company's system - is an event that can trigger other events in other systems, such as billing, email, etc. Instead of having the producer calling the billing system directly, which would be tightly coupled, in the event-driven architecture we basically hide both, keeping them apart from each other.
This way, the producer system will send an event to an event bus, which will be listened to by the consumer. An event does not carry much data on it; it only carries the information that is necessary for the consumers to be able to do their job. 
This approach helps developers in terms of application responsiveness. On monolith systems, the whole application is coupled together, so when scaling needs to happen, the whole application has to be taken down. In fact, the entire application has to be deployed every time there is a single change in one part of the system.
Event-driven architecture was created to help developers have a decoupled and responsive application. Because of this, it has been widely used in applications that have been broken down from monoliths to microservices.
Event Notification
Most of the time, producers do not care about receiving responses from consumers. Producers don't want to know about the existence of consumers or what they are doing with information. They just want to convey information about an event for another system to work on. This is called event notification. It segregates the responsibilities of each service.
Event Source
A common pattern when we talk about event-driven architecture is event sourcing. This core concept enables systems to process the event at any time in the future since all events are logged, and the state of the application will depend on the order of its insertion. Examples of this pattern include the version-control system GIT and change logs of databases.
Event Stream
From event sourcing, stream processing tools were created in order to permit the development of systems that process information in parallel. Apache Kafka framework is a very good example of how the event stream works. It stores the events, in the same order as they were received, in logical collections called topics. Topics can be imagined as queues and are grouped into partitions that permit parallel processing.
Final Considerations
In part one of this series, you were introduced to the EDA concepts that have been driving the world of microservices. It's important to note that even though there are advantages to using this architectural design, there are also challenges.
For example, this approach requires much more expertise from developers, since there may be debugging and testing problems that are far more difficult to resolve due to their asynchronous nature. This architecture also requires a lot from DevOps teams, since they need to control the flow of what is happening in an application because it's essential to know if everything is up and running correctly.
When choosing an architectural pattern, choose wisely and select a pattern that meets your business requirements. If you have a requirement that has divided transactions that are processed separately, EDA may be the pattern that you are looking for.
