Event-driven architecture has become popular for its ability to ingest, process, and react to events in real-time. Event-driven is not a new paradigm however the proliferation of microservices and serverless computing has led to its ability to fully realize the benefit of its loosely coupled design to reach infinite scale without the need to manage infrastructure.
Moving to an event-driven architecture requires a restructuring of how you think about your application. To adopt an event-first mindset, you should first consider what business processes could be optimized to deliver customer value. These business processes can then be distilled down to a workflow of events.
What is an event?
An event is a lightweight notification of a condition or a state change that occurs in your environment. Events are produced from event sources where the state change has taken place. Events exist in many forms from checking code into source control or hiring a new employee and now several actions need to follow.
What is event-driven architecture?
Event-driven architecture is a distributed system pattern that uses events to communicate between loosely coupled microservices to produce highly scalable applications. An event-driven architecture consists of event producers that generate a stream of events, and event ingestion that processes messages to the appropriate event consumers. Producers and consumer services are decoupled, which allows them to be scaled, updated, and deployed independently.
Polling based vs event-driven architectures
In a polling based architecture when you want to respond to events it can be difficult to discover those events, often you must write specific code across different API’s and SDK’s to continuously poll, looking for changes from the desired event source. Polling based architectures are synchronous so clients must wait for initial processes to complete before it can move onto the next one.
In an event-driven architecture, events are processed asynchronously which keeps threads running independently, instead of having to wait for a reply before moving onto the next task. One of the best practices for event driven architectures is using an event broker. Event producers and event consumers aren't tightly coupled, so you can change producers and consumers just by communicating with the broker.
Azure Event Grid is the event broker backplane that enables event-driven, reactive programming. You can publish any event to event grid, add consumers to event grid and lower costs by eliminating the need for constant polling. Event grid is serverless so you get the benefits of publishing and subscribing to messages without the overhead of setting up the necessary infrastructure.
Since event-driven architectures are composed of loosely coupled distributed services, serverless application components can react to events in near real-time with virtually unlimited scalability. Services such as Azure Functions or Logic Apps easily integrate with Event Grid allowing you to build serverless event-driven applications.
What are the benefits of event-driven?
- Loosly coupled: can add, remove, version as your architecture grows. You can easily add in a new event consumer and the other ones don't have to know about it
- Highly composable: can use and reuse different event driven components throughout your solution
- "Single purpose" units of code: Event driven architecture can help you keep your code from getting too complex by breaking into more discrete parts
- Maps to the business need: Your team is building code based off of the actual business events. "When a sale happens" is the event, so what should happen when a sale happens? Ideally the real world events are represented in your solution.
Example Scenario
Event-driven architecture
One of the more common event patterns is when a customer places an order on an e-commerce site. When an order is placed, an event is created with all the information necessary for other services to carry out the completion of the order. The task of completing the order would involve several actions that would be processed by different systems: payment is processed, an email is sent to a customer, inventory is accounted for, the shipping label is produced, etc. These actions occur asynchronously so services do not have to wait on another to complete their task.
When you should use this architecture
Use cases for event-driven architecture are typically driven by the need to have near real-time processing and multiple subsystems processing the same events. Many of the common applications include IoT applications, e-commerce, financial systems, and data analytics.
The decision to use a request-driven vs event-driven architecture ultimately boils down to what problem are trying to solve and how you will benefit from the solution. Event-driven is not the answer for all scenarios however it is a great first step to begin thinking about business-processes as first-class events that ultimately derive customer value.
Summary
Transitioning to an event-driven architecture is an opportunity to modernize your systems to keep up with the fast-changing business environment. Paired with a serverless infrastructure, event-driven architecture provides the agility necessary to scale on-demand and independently make changes or update services.
In the next blog in the series, I will focus on how you can architect event-driven applications using common messaging patterns and capabilities in Azure.
To learn more about event-driven architecture on Azure, check out Event-driven architecture.
Microsoft
