What you need to know about event driven architecture

Before getting started with details of an event driven architecture, it is important that we understand some of the terminology relevant to this topic:

• Event Emitter : A component of a system that is responsible for notification that an event has occurred.
• Event Consumer : A component of a system that is responsible for reacting to the emitted event.
• Event Channel : The mechanism by which events are transmitted from event emitter to event consumer.

What is event driven architecture?

Event driven architecture is one of many patterns used in software design. This pattern can be applied at many levels within a system. This can range from an enterprise level implementation where there are many applications around the world communicating with each other to perform activities, to a localized implementation where there are processes running on the same server communicating with each other. It could even be a small desktop application, where the presentation layer is reacting to the user's interaction. As you may already be seeing, the event driven pattern has a wide array of use cases in software development.

How does it work?

The event in this architecture is a change in state. Once a change in state occurs within a system, the event emitter is then tasked with identifying and gathering the event. With the event gathered, the event emitter's next task is notify the event channel. The event channel is then responsible for notifying any and all event consumers of the change in state. There is no requirement that there be an event consumer to handle the event. Moreover, there is an ability to register multiple event consumers to handle a single event. This emitting and consuming of events can execute in a synchronous or asynchronous fashion, giving the implementers more options to build the system that appropriate for their use case.

Benefits of choosing this architecture?

Now that we have a better understanding of the mechanics of the architecture more, let's review benefits. We can see event driven architectures are very loosely coupled. As we read above, the change in state does not even know of the event emitter, let alone the potential for zero to many event consumers. Given that multiple event consumers are able to register to a particular event, the system can react to a single event in many different ways. This loosely coupled architecture then opens to the opportunity to distribute one system into many much smaller sub-systems. This ability to decompose one system in to many sub-systems has a great amount of power. The development team can grow into teams easier as one huge code base gets broken into many much smaller code bases. The deployment of a monolithic systems is broken into many much smaller deployments reducing overall risk. In this scenario, where the event emitters and event consumers are separate sub-systems, we then have an opportunity to vertically and horizontally scale both sub-systems independent of each other. Lastly, event driven architecture allows for event durability. As systems begin to communicate with each other the possibility that one system is not available increases. Events can be queued or persisted in some manner, such that when the event consumer is available again, the reactions to the event will still occur.

What are some common frameworks implementing this architecture?

• ASP.NET Web Forms
• Windows Presentation Foundation
• Java Swing
• JavaScript events