Event Driven Architecture

Understanding Event Driven Architecture

Event–driven architecture (EDA) is a software architecture pattern in which the flow of the program is determined by events. An event can be generated by the user, by the system, or by another program. When an event occurs, the program responds by executing a piece of code, which is known as an event handler.

To say it another way, this software architecture pattern promotes the production, detection, consumption of, and reaction to events. An event can be defined as “a significant change in state”.[1] For example, a user clicking on a button would generate an event. Event-driven architectures are designed to handle events asynchronously. Event-driven architectures are often used in conjunction with event sourcing.

EDA was first proposed by Gartner analyst Richard Monson-Haefel in his book Enterprise JavaBeans (1999).[2]

Components, Advantages, and Challenges

The term “event–driven architecture“ has been used in various contexts and can mean different things to different people. In some cases, EDA is conflated with event–driven programming, event sourcing, or even reactive programming. However, these are all separate concepts.

EDA is a architectural pattern, not a specific technology. That said, there are many technologies that can be used to implement an EDA. For example, Apache Kafka, RabbitMQ, and AWS Kinesis are all popular event streaming platforms that can be used to build an EDA.

An event–driven architecture typically consists of three major components:

• Events: These are the “things“ that happen in the system. For example, a user clicking on a button, or a sensor detecting a change in temperature.
• Handlers: These are the components that “handle“ events. In most cases, a handler will be some sort of software component (e.g. a piece of code) that is triggered when a particular event occurs.
• Event Bus: This is the “glue“ that ties everything together. The event bus is a message queue that events are published to. Handlers can then subscribe to the event bus and consume events that they are interested in.

There are many benefits to using an event–driven architecture. For example, it can make a system more scalable, more resilient, and more responsive.

• EDA can make a system more scalable because it decouples components from each other. This means that each component can scale independently of the others.
• EDA can make a system more resilient because it allows for event handling to be retried in the case of failure. This can help to ensure that the system as a whole is still able to function even if individual components are not working correctly.
• EDA can make a system more responsive because event handling can be done asynchronously. This means that the system can continue to operate even if some parts of it are slow or unavailable.

Event driven architecture is not without its drawbacks. You’ll hear about one of the biggest challenges with EDA is managing the complexity that can come with having a lot of events and handlers. Another challenge is ensuring that events are processed in the correct order.

Despite its challenges, EDA is a powerful architectural pattern that can be used to build systems that are scalable, resilient, and responsive.

Considerations

We should keep a few key considerations in mind when designing an event–driven architecture:

1. Loose coupling: Services should be able to communicate with each other without depending on each other. This allows for more flexibility and easier maintenance in the long run.
2. Asynchronous communication: Services should be able to communicate asynchronously, so that one service can continue processing even if another service is unavailable.
3.  Scalability: The architecture should be able to scale horizontally and vertically as needed.
4. Robustness: The architecture should be able to handle failures gracefully and recover from them automatically.

History and Patterns of EDA

Event–driven architecture (EDA) is a software architecture pattern promoting the production, detection, consumption of, and reaction to events. An event can be defined as “a significant change in state“. For example, when a consumer purchases a car, the car‘s state changes from “for sale“ to “sold“. A car dealer‘s inventory system would be designed to detect such a state change and take appropriate actions – updating the inventory database, notifying the sales department, and generating a receipt for the customer.

The term “event–driven architecture“ has been used in the software industry at least since the early 1990s. The concept is similar to the message–oriented middleware and enterprise messaging systems of the same era.

In general, it is one where the overall flow of control is determined by events, rather than by direct programmatic flow control.

One common type of EDA is the publish–subscribe pattern, in which event producers publish events to a central event bus, and event consumers subscribe to the bus and receive events that they are interested in. This pattern is often used in distributed systems, where it can be used to decouple event producers and consumers, and to allow different parts of the system to scale independently.

Another common type of EDA is the observer pattern, in which objects register themselves as observers of other objects, and are notified when events of interest occur. You will see this pattern often used in GUI applications, where the user interface components need to be updated in response to changes in the underlying data model.

The term “event–driven architecture“ can also be used more broadly to describe any architecture where events play a central role. For example, in a microservices architecture, each microservice may be regarded as an event producer, and the overall system may be event–driven in the sense that the flow of control is determined by the sequence of events that are generated by the microservices.

The Future of Event-Driven Architecture (EDA)

The future of event–driven architecture looks very promising. With the rise of microservices and the need for more flexible and scalable systems, event–driven architecture is well–positioned to be a key player in the next generation of software development.

We should note a few key trends that are driving the future of EDA:

1. The rise of microservices
2. The need for more flexible and scalable systems
3. The growth of the Internet of Things

You may have noticed microservices are becoming increasingly popular as a way to build more scalable and flexible applications. Event–driven architecture is a perfect fit for microservices, as it allows for loose coupling between services and makes it easy to add new services or change existing ones.

The Internet of Things is another key driver for the future of event–driven architecture. As more and more devices are connected to the internet, the need for systems that can handle high volumes of data and events is only going to grow. Too, event–driven architecture is well–suited for dealing with large volumes of data and events, making it a key technology for the future of the Internet of Things.