Event Driven Architecture — What is it and why now
Event Driven Architecture is generating a lot of attention of IT practitioners and seeing increased adoption. In order to understand this phenomenon better we need to understand what events are, how building IT architecture around events helps organizations and finally why it is relevant in this day and age.
An “event” in an event driven architecture can be defined as: “Event represents “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 system architecture may treat this state change as an event whose occurrence can be made known to other applications within the architecture”. Events additionally have some characteristics, they are immutable — cannot be changed or deleted, and they are sequenced based on the time of occurrence. Nothing new here, it is clear from the above definition that events have been existing from a very long time, what is new however is how and when we use them in designing and building our applications.
Till recently the default architectural style adopted to store objects and their state details has been by way of recording this information in a Database (Relational DB). Any application interested in finding the current state of the object would be expected to query the database. This practice ensured consistency in recording the state information and a uniform way of accessing that information. But it also introduced delay and was not very scalable. Every new application that is interested in an object and its current state was expected to program itself to query the DB, this also created tight coupling between the application and the database.
In contrast to the above the Event driven architecture pattern consists of loosely coupled applications which can be classified as event emitters (“Source” applications which generate events) and event consumers (applications which are interested in consuming the events). The event emitters do not know anything about the consumers, they detect, gather and generate events which is held by an Event broker. The Event broker component leverages a messaging backbone, this is typically a distributed log such as Apache Kafka. This distributed log is an ordered set of events and they can be persisted as long as needed. Event consumers keep track of how many events they have consumed from the log using offsets. A brand-new application can be added as a consumer and it can consume events from the beginning. This architecture allows applications to be completely decoupled and provides horizontal scalability options.
Let us now look at why Event Driven Architecture is gaining in popularity and relevance right now:
Application Modernization and adoption of Micro Services Architecture: As we modernize large monolithic applications into multiple smaller micro services synchronous invocation creates dependency, adopting event driven architecture ensures true decoupling between applications. The event producer and consumers can be coded using any language or platform of choice, can be scaled horizontally and can be added or removed without cascading impact.
Proliferation of Data: The amount of Data that is being generated is increasing at an exponential rate. This could be data from IoT sensors, customer data based on their digital interactions, location, past behavior/preferences etc. Event driven applications can be made to consume this stream of data efficiently and in a scalable manner. Using this approach, we are able to enhance customer experience by providing them with real time and relevant information. The event streams can also be used to drive effective data science and machine learning projects within the organization.
With our vast Integration experience, we in GBM can help you in getting started with this transformation, please get in touch if you plan to embark on adoption of Event Driven architecture.
