What is event-driven architecture?
Event-driven architecture (EDA) is an integration model that detects important “events” in a business – such as a transaction or an abandoned shopping cart – and acts on them in real time.
Event-driven architecture overview
Almost every event in a business is time sensitive. When a customer makes an online purchase, a sensor flags an impending malfunction, a stock price drops, or a security breach is detected – immediate action needs to be taken. This is where an event-driven architecture (EDA) comes in. An EDA can create, detect, and respond to events as they unfold, helping businesses improve everything from customer experiences to operational efficiency and agility.
What is an event?
First, some basics. An event is any action or change of state that is important to a business. For example, when someone swipes a credit card, checks in for a flight, or resets a password – or when inventory is updated in a warehouse. Events are happening all the time, in every organisation, in every industry. Companies become “event driven” when they can capture and react to events as they occur.
What is an event-driven architecture?
An event-driven architecture (EDA) is an integration model built to publish, capture, process, and respond to events across distributed systems in real time. When an event occurs in one application, a message is automatically sent to all the other applications that need to know about it, so they can act on it in turn.
Event-based architectures are decoupled – meaning applications don’t need to be aware of each other to share information and complete tasks. Event information, or messages, can flow freely and automatically between apps. As a result, the EDA model is much faster than the traditional request/response model, where one application must request the specific information it needs from another and wait for a response before moving on to the next task. Also due the decoupled nature of an EDA, they are widely considered best practice for microservice communication.
How does an EDA work?
In an event-driven architecture, applications act as event producers (apps that produce or capture events) or event consumers (apps that process and act on events). Producers transmit events to consumers via a broker, aka messaging-orientated middleware, in real time. Consumers can then process the event and trigger other actions, workflows, or events of their own.
In a very simple architecture – when there is a single producer and a single consumer that are in direct communication with each other – brokers can be optional. However in most enterprises there are multiple sources sending out events to multiple consumers, so a broker, or even a network of brokers (also known as an “event mesh”) is needed. When a broker or an event mesh is used, this creates a “loose coupling” of applications.
Event-driven architecture patterns
There are two main patterns for transmitting events in an event-driven architecture: publish/subscribe and event streaming.
Publish/subscribe (aka “pub/sub”) – With pub/sub, event consumers subscribe to messages and channels published by event producers. When an event is published, it is sent directly to all subscribers via a broker. To avoid duplication, events cannot be replayed or accessed once consumed – they are deleted by the broker.
Event streaming – With event streaming, producers publish entire streams of events to a broker. Consumers subscribe to the stream and can read from any part it, consuming only the events that are relevant to them. With this pattern, events are retained by the broker even after they are consumed.
3 approaches to event processing
There are three different approaches to processing events once they reach a consumer: simple event processing, complex event processing, and event stream processing.
- Simple event processing: Consumers process each event as it is received.
- Complex event processing: Consumers process a series of events to detect patterns and perform actions based on the result.
- Event stream processing: Consumers process and act on a constant flow of data (data in motion) in real time using a data streaming platform.
Businesses choose their approach to event processing based on their individual needs and use cases.
Event-driven architecture use cases and examples
There are many different use cases for event-driven architectures in every industry – from banking to retail. Here is an example from the restaurant industry:
A college student places an order for a pizza via a food delivery app, such as Uber Eats. The app captures his basic information (name, address, payment info, and order) and publishes the “pizza order” event.
The pizza restaurant subscribes to the event, fulfils the order, and publishes its own “order ready” event back to the food delivery service
The service then allocates a delivery driver, schedules an ETA, and alerts the customer that his pie is on the way
An EDA example from e-commerce:
On online shopper enters their credit card details on an e-commerce site, which publishes the “payment submitted” event
The payment system subscribes to the event, processes the payment, and issues its own “payment processed” event indicating success or failure – and routes it back to the website UI
The UI shows the payment status to the customer and prompts next steps
Some other examples of EDA include:
When an online shopper clicks on a product and the system responds by generating product recommendations based on similar items
When a customer deposits a check at a bank and the system automatically posts the deposit to their account
When a retailer screens global transactions for fraud and flags any suspicious purchases to the credit card company
When a manufacturer monitors streaming IoT data from its equipment and is alerted to any potential maintenance issues or failures
Benefits of an event-driven architecture
There are many benefits of an event-driven architecture. The top 3 are:
- Real-time workflows and responsiveness. An EDA can monitor and quickly react to events as they occur, often using robotic process automation (RPA) to accelerate workflows and trigger next steps in real time. This is especially critical during times of peak demand – for example, during major sales events or holidays. This responsiveness can also be applied to everyday (i.e. non-peak) workflows, improving everything from supply chain automation to fraud detection.
- Asynchronous messaging. Applications in an EDA communicate asynchronously – meaning producers publish event messages without waiting for consumers to receive them. Not only does this let applications move on to other tasks without waiting, it simplifies integration.
- De- and loose coupling. Applications in an EDA are de-coupled or loosely coupled and are not dependent on each other’s availability. They can be updated, tested, and deployed independently. They can also fail independently – so the architecture is more durable and persistent than traditional models. Decoupling also makes it easy to add extra publishers and consumers as needed, eliminating the need to rewrite code every time there is a change.
Conclusion
Event mesh offers deployment options across different hyperscalers and in private cloud environments. It can be configured to form a distributed mesh of event brokers deployed across environments in private or public clouds. Event mesh offers a full purpose set of eventing services, including event streaming, event management, and monitoring, and advanced features like dynamic message routing and fine-grained filtering.
Explore SAP’s event mesh capabilities
Power your apps with an event-based architecture from SAP Integration Suite.
Ideas you won’t find anywhere else
Sign up for a dose of business intelligence delivered straight to your inbox.