Event-driven architecture is a software architecture paradigm that promotes production, detection, consumption of, and reaction to events, mainly in application building, This model for application design allows organizations to detect events, such as important business moments, and act on them in real time. Many modern application designs are event-driven, such as customer engagement frameworks that use customer data in real time.
What is an event?
An event is any significant occurrence or change in a state for system hardware or software. Events can be user actions, such as clicking a mouse button or pressing a key, or system occurrences, such as running out of memory. Most modern applications, particularly those that run in Macintosh and Windows environments, are said to be event-driven, because they are designed to respond to events.
How event-driven architecture works
Event-driven architecture is made up of event producers and event consumers. An event producer detects an event and represents that event as a message. It doesn’t know the consumer of the event or the outcome of it. An event consumer applies restrictions as soon as events are presented.
After an event is detected, the event producer transmits it to the event consumer through an event channel. Here, an event processing platform processes the event asynchronously. An event consumer needs only to be informed when an event has occurred. They might process the event, or may only be impacted by it.
The event processing platform executes the correct response to the event and sends the activity to the appropriate event consumers. This activity is where the outcome of an event is seen.
Event-driven architecture is loosely coupled, meaning event producers don’t know which event consumers are listening for an event. Likewise, the event doesn’t know what the consequences are of its occurrence. Minimal coupling makes this kind of architecture a good option for creating event-driven applications.
It can be helpful to understand the concept by picturing a hotel lobby. You press the “up” button on the elevator so you can get to the third floor. The elevator responds and travels down to the lobby. It opens, you step inside, press the “3” button, and the elevator takes you to the respective floor where it opens its doors and lets you out.
Pressing the “up” button produced the event. The event producer, the elevator’s operating system, processed the request and sent it to the event consumer. The elevator car processed the trip from the top floor to the ground floor to the third floor. But none of this happened until the event of pushing the button happened. The event consumer, the button, didn’t know anything about what the elevator did or whether it was successful.
Event-driven architecture processing styles
There are three general styles of event processing that are often used together in a mature event-driven architecture framework.
Simple event processing
An event immediately triggers an action in the event consumer.
Complex event processing
An event consumer processes a series of events in order to detect patterns.
Event stream processing
A data streaming platform is used as a pipeline to ingest events then process or transform the event stream. This can be used to detect meaningful events in event streams.
