Event-driven architecture is an integration model built around the publication, capture, processing, and storage (or persistence) of events. When an application or service performs an action or undergoes a change that another application or service might want to know about, it publishes an event—a record of that action or change—that another application or service can consume and process to perform actions in turn.
Event-driven architecture enables a loose coupling between connected applications and services—they can communicate with each other by publishing and consuming events without knowing anything about each other except the event format. This model offers significant advantages over a request/response architecture (or integration model), in which one application or service must request specific information from another specific application or service that is expecting the specific request.
Event-driven architecture maximizes the potential of cloud native applications and enables powerful applications technologies, such as real-time analytics and decision support.
In an event-driven architecture, applications act as event producers or event consumers (and often as both).
An event producer transmits an event—in the form of a message—to a broker or some other form of event router, where the event’s chronological order is maintained relative to other events. An event consumer ingests the message—in real-time (as it occurs) or at any other time it wants—and processes the message to trigger another action, workflow, or event of its own.
In a simple example, a banking service might transmit a ‘deposit’ event, which another service at the bank would consume and respond to by writing a deposit to the customer’s statement. But event-driven integrations can also trigger real-time responses based on complex analysis of huge volumes of data, such as when the ‘event’ of a customer clicking a product on an e-commerce site generates instant product recommendations based on other customers’ purchases.
There are two basic models for transmitting events in an event-driven architecture
Event messaging or publish/subscribe
In the event messaging or publish/subscribe model, event consumers subscribe to a class or classes of messages published by event producers. When an event producer publishes an event, the message is sent directly to all subscribers who want to consume it.
Typically a message broker handles the transmission of event messages between publishers and subscribers. The broker receives each event message, translates it if necessary, maintains its order relative to other messages, makes them available to subscribers for consumption, and then deletes them once they are consumed (so that they cannot be consumed again).
In the event streaming model, event producers publish streams of events to a broker. Event consumers subscribe to the streams, but instead of receiving and consuming every event as it is published, consumers can step into each stream at any point and consume only the events they want to consume. The key difference here is that the events are retained by the broker even after the consumers have received them.
A data streaming platform, such as Apache Kafka, manages the logging and transmission of tremendous volumes of events at very high throughput (literally trillions of event records per day, in real-time, without performance lag). A streaming platform offers certain characteristics a message broker does not:
Compared to the request/response application architecture, event-driven architecture offers several advantages and opportunities for developers and organizations.
Powerful real-time response and analytics: Event streaming enables applications that respond to changing business situations as they happen and make predictions and decisions based on all available current and historical data in real-time. This has benefits in any number of areas—from processing streams of data generated by myriad IoT devices, to predicting and squashing security threats on the fly, to automating supply chains for optimal efficiency.
Fault tolerance, scalability, simplified maintenance, versatility, and other benefits of loose coupling: Applications and components in an event-driven article aren’t dependent on each other’s availability; they can be independently updated, tested, and deployed without interruption of service, and when one component goes down a backup can be brought online. Event persistence enables ‘replaying’ of past events, which can help recover data or functionality there is an event consumer outage. Components can be scaled easily and independently of each other across the network, and developers can revise or enrich applications and systems by adding and removing event producers and consumers.
Asynchronous messaging: Event-driven architecture enables components to communicate asynchronously—producers publish event messages, on their own schedule, without waiting for consumers to receive them (or even knowing if consumers received them). In addition to simplifying integration, this improves the application experience for users. A user completing a task in one component can move on to the next task without waiting, regardless of any downstream integrations between that component and others in the system.
In microservices—a foundational cloud native application architecture—applications are assembled from loosely coupled, independently deployable services. The main benefits of microservices are essentially the benefits of loose coupling—ease of maintenance, flexibility of deployment, independent scalability, and fault tolerance.
Not surprisingly, event-driven architecture is widely considered best practice for microservices implementations. Microservices can communicate with each other using REST APIs. But REST, a request/response integration model, undermines many of the benefits of the loosely coupled microservices architecture by forcing a synchronous, tightly coupled integration between the microservices.
IBM Event Automation puts events to work by enabling business and IT users to detect situations, act in real time, automate decisions, and maximize their revenue potential.
An AI-powered integration software solution, IBM Cloud Pak® for Integration provides a comprehensive set of integration tools within a single, unified experience to connect applications and data across any cloud or on-premises environment.
IBM Cloud Pak® for Data is an open, extensible data platform that provides a data fabric to make all data available for AI and analytics, on any cloud.
IBM Streams is an advanced analytic platform used to ingest, analyze and correlate information from different data sources in real time.
REST APIs provide a flexible, lightweight way to integrate applications, and have emerged as the most common method for connecting components in microservices architectures.
In a microservices architecture, each application is composed of many smaller, loosely coupled and independently deployable services.
A message broker is software that enables applications, systems, and services to communicate with each other and exchange information.
IBM Event Automation, a fully composable solution, enables businesses to accelerate their event-driven efforts, wherever they are on their journey. It offers event distribution, event discovery and event processing capabilities in an intuitive interface so both business and IT users can put events to work and respond in real-time.