What's On The Agenda?
In today's lesson, we'll delve into the fascinating world of Event-Driven Architecture (EDA) and its most commonly used messaging pattern, the Publish/Subscribe model (Pub/Sub). We'll cover:
- Why Event-Driven Architecture is crucial in modern workflows
- How it enables seamless, real-time communication between different system components
- What sets it apart from more "traditional" methods
- When to opt for an Event-Driven Architecture
The Rise of Distributed Systems
In nearly every industry, distributed software systems have become the backbone of business operations. This leads us to a critical challenge: how do you enable various systems to talk to each other efficiently?
What is Event-Driven Architecture in Simple Terms?
Imagine you're at a party. You have clusters of people engaged in various conversations. Suddenly, someone makes an announcement about serving dinner. Everyone interested in eating gathers around the dining table. No one needed to go around and individually tell people that dinner is ready. That announcement is an "event," and the people reacting to it are elements of an "event-driven system."
In technical terms, Event-Driven Architecture is a software design pattern that enables different system components to communicate through events. Each component can publish events or subscribe to them, without needing to know who else is involved.
Pub/Sub: The Popular Kid on the Block
The Publish/Subscribe model, or Pub/Sub, is the most popular messaging pattern used in Event-Driven Architecture. Here's how it works:
- Publishers: Components that announce or "publish" events.
- Subscribers: Components that listen or "subscribe" to events.
- Event Bus: A common platform where events are broadcasted and received.
The main advantage is that publishers and subscribers don't need to know about each other, offering greater system decoupling.
Why Choose Event-Driven Architecture?
- Real-time Communication: Enables instant data sharing between components.
- Scalability: Easily add more components without significant codebase changes.
- Loose Coupling: Components can function independently, reducing the system's overall complexity.
When is Event-Driven Architecture a Good Fit?
- When you need real-time updates.
- If you have various independent systems that need to share data.
- For highly scalable systems.
Demystifying Event-Driven Architecture
The Nuts and Bolts of EDA
Event-Driven Architecture (EDA) is more than a buzzword; it's a robust design pattern that transforms how software systems interact. Tailored for real-time or near real-time communication, EDA is particularly valuable in a microservices environment, where each service operates in its own process.
What Makes EDA Special?
Here are some key characteristics that set EDA apart:
- Distributed: The architecture spans multiple services or components.
- Asynchronous: Communication doesn't happen in lockstep; services don't wait for each other.
- Highly Scalable: Adding more components to the system is straightforward.
The Role of Events
In this architecture, events are the heroes. They act as the triggers that facilitate communication between services that are otherwise unaware of each other's existence. Think of an event as a messenger pigeon that carries news from one service to another.
Not a Replacement, but an Enhancement
Let's be clear: EDA is not here to replace existing architectural paradigms. Instead, it enriches them by enabling real-time value extraction from organizational events.
A Three-Step Dance
To make it even simpler, think of event-driven development as a dance that involves three steps:
- Event Creation: One service generates an event to signify a change or action.
- Event Communication: The event is dispatched to an intermediary, like an event bus, from where it can be picked up.
- Event Consumption: Another service subscribes to the event and takes action when it occurs.
Event-Driven Architecture offers a powerful lens through which to view and design complex, distributed systems. It is like the neural network of an organization, transmitting signals (events) that help various parts (services) react in a coordinated manner.
Are you sure you're getting this? Is this statement true or false?
In EDA, events trigger communication between decoupled services.
Press true if you believe the statement is correct, or false otherwise.
Event-Driven Architecture Models
Generally, event-driven architecture is based on either a Pub/Sub model or an event stream model. This article will discuss the Pub/Sub model.
What is Pub/Sub?
Pub/Sub, which stands for Publisher/Subscriber, is a messaging architecture based on event stream subscriptions that allow applications and services to share event data. In terms of the Publishers-to-Subscribers relationship, it is a software design that sends an email to those who need to be notified when an event occurs or is published. The data that is shared can be anything from strings to complex objects representing text, sensor data, audio, video, or other digital content.
There are three basic terms that define the Pub/Sub messaging architecture:
Topic: A topic is a shared string that lets apps communicate with one another over a common thread.
Publishers: Publishers transmit the messages. They are unaware of the information's destination.
Subscribers: Subscribers receive messages. They have no idea where the information comes from. Subscribers will only receive information with themes that they have already agreed to receive.
Try this exercise. Click the correct answer from the options.
Which of the following are EDA models?
Click the option that best answers the question.
- Pub/Sub Model
- Event Stream Model
- Both A and B
- Neither A nor B
Understanding Pub/Sub Message Flow: A Visual Journey
The Big Picture
Let's consider a diagram that outlines the Pub/Sub (Publish/Subscribe) message flow. Imagine it like a postal service, but for digital messages. Here's how it works:
Breaking Down the Flow
The Publisher's Role: Picture the publisher as the person who writes a letter. They create a message and send it to a specific destination, known as the "topic."
Topic as a Mailbox: The topic serves as a kind of mailbox or storage area. It holds the message until it can be delivered to the subscribers.
Message Forwarding: The message doesn't stay in the topic forever. It's like a package being picked up from the mailbox and sent out for delivery.
Subscriber's Reception: The subscriber, waiting eagerly like someone expecting a letter, receives the message through a "push" operation activated by the Pub/Sub system.
Acknowledgment: Once the message is received, the subscriber sends back an acknowledgment, like signing for a package.
Message Removal: After acknowledgment, the message is removed from the queue, like throwing away the packaging after opening a parcel.
The Loop is Closed
In this way, the Pub/Sub system ensures that messages are not just sent but also successfully received and acknowledged. It's a full-circle process that ensures efficient, reliable communication.
Patterns of the Pub/Sub EDA
Broadcast Pattern
In this pattern, the information is provided once to all participants. Participants hold if the information interests them or they discard the information if not. This approach works effectively if it is possible to efficiently discard the unnecessary information. Furthermore, since many network techniques distribute bandwidth among a number of devices, sending a message via broadcast typically consumes no more capacity on the network than sending it to all of the computers.
Polling Pattern
In this pattern, participants can contact the sender on a regular basis to check if they have anything that interests them. A downside of this pattern is wasting time. You may receive hundreds of emails from subscribers but have nothing new to offer them. On the other hand, some people may miss information if there are two updates sent in a row.
Try this exercise. Click the correct answer from the options.
Participants can contact the sender on a regular basis to check if they have anything that interests them in which pattern?
Click the option that best answers the question.
- Broadcast Pattern
- Polling Pattern
- Both A and B
- Neither A nor B
Common Pub/Sub Use Cases
Event-driven apps are popular for a wide range of use cases because they allow users to make real-time business choices based on the most up-to-date data. We'll go over a couple of them below.
Healthcare
With so much data created in real-time by IoMT devices, wearables, and other medical equipment, it's vital to act quickly when there is new information and to recognize key moments sooner. Remote patient monitoring, preventive maintenance of medical diagnostics equipment, and more proactive healthcare, in general, are all possible thanks to the event-driven method of processing data.
Banking
With EDA, it's possible to monitor transactions in real-time, detect fraudulent activity as it occurs, and promptly warn a cardholder of suspected card fraud via phone.
Online shopping
EDA can be used to integrate the services involved in eCommerce operations. From order placement to shipment, events are broadcasted in real-time which enables real-time visibility and fast response to consumer interactions and orders.
Internet of Things
IoT solutions are used in a variety of industries, including transportation and healthcare. Sensor data streams, temperature readings, position locations, and other state changes can all be captured via events in IoT devices. EDA enables the immediate processing of large volumes of data provided by IoT-based environments and devices. As a result, it's possible to address difficulties and prepare preventative measures manually or to automate decisions.
Benefits of EDA
Almost every application or service designed today expects that you can do everything you want to right now, that you can get rapid feedback on the progress of your request, and that you can communicate with the request and anybody else participating in the process in real-time. Everything today is event-driven, whether it's shopping, manufacturing, banking, or messaging. Below are some of the advantages of this event-driven design for making that demand more manageable and widespread.
Develop with Agility
The key benefit is that you don't have to write any own code to poll, filter, or route events since an event router automatically filters and pushes events to consumers. The router reduces the need for considerable coordination between producer and consumer services, allowing projects to be executed more quickly.
Cost Reduction
Because event-driven architectures are push-based, everything happens as soon as the event appears in the router which means that you don't have to pay for continuous polling to check for an event. This translates to lower network bandwidth usage, CPU utilization, idle fleet capacity, and SSL/TLS handshakes.
Audit with Ease
An event router serves as a central point for auditing and defining policies for your application. These policies can limit who can publish and subscribe to a router as well as who has access to your data. Your events can be encrypted in transit and at rest.
Conclusion
To summarize, using an event-driven approach provides numerous advantages that are becoming increasingly important for businesses to survive and prosper in an increasingly competitive, consumer-driven environment. However, more important than any specific approach is the overall integration strategy which aids in avoiding frequent mistakes.
One Pager Cheat Sheet
- Event-driven architecture (EDA) and the
publish/subscribe (pub/sub)
messaging pattern provide real-time communication between distinct components without requiring them to be aware of each other, making it a popular choice for efficient application design. - Event-Driven Architecture (EDA) is a
software architectural paradigm
that facilitates communication between distributed software systems throughasynchronous
and highlyscalable
events. - In EDA, an
event
acts as the catalyst for communication betweendecoupled services
. - Generally, Pub/Sub (Publisher/Subscriber) is an event-driven architecture in which Publishers send messages over a Topic, and Subscribers receive messages related to their subscribed topics.
- A and B are both Event-Driven Architecture (EDA) models, where events are sent to topics and are subscribed to by either publishers or subscribers.
- The
Pub/Sub
architecture publishes a message to a topic, which is then forwarded to a subscription and pushed to a subscriber, who sends an acknowledgment back before the message is removed from the queue. - The Broadcast Pattern sends the same message to all participants, while the Polling Pattern regularly contacts the sender to check for updates, but may waste time or cause people to miss information.
- The
Polling Pattern
is a method for a subscriber torequest
information from a central source at set intervals in order to make sure the content is up-to-date. - Pub/Sub technology enables real-time event-driven applications to make proactive decisions based on the most up-to-date
data streams
from various industries, such as Healthcare, Banking, Online Shopping, and Internet of Things. - Event-driven design
(EDA)
allows for rapid development with agility and cost reduction, as well as ease of auditability, making it a highly attractive software architecture. - Event-driven architectures provide many advantages and require an effective integration strategy for success.