In this video, we explore the fundamentals of event-driven architecture, illustrating its application through real-world scenarios. Learn how this architecture works by understanding the roles of publishers and subscribers, the significance of events as data packets, and the efficient, modular approach it offers for system design. Whether you’re a seasoned professional or new to the field, this guide provides a clear understanding of how event-driven architecture facilitates efficient, incremental, and effective system development. Join us as we unravel the intricacies of this dynamic architectural framework.
Watch and enjoy!
Here’s the video transcript:
Today, we’re going to answer the question: What is an event-driven architecture? There are many scenarios in technology where you can write requirements in the form of “if this, then that.” If you find that’s the case, the chances are that you’re looking at some form of event-driven architecture. So, when we look at that from an architectural perspective, what it typically means is that you will have some application, some system that acts as a publisher. This is the one that detects the event.
So, an event could be something like we’ve just received an order, or I’ve updated the customer record, or this customer has just paid their bill. Then, that system emits an event. An event is effectively a small message. It’s a packet of data that describes all the things you might be interested in, which might include your customer ID, the timestamp, what they’ve done, and any other relevant details. For instance, if they’ve paid their bill, it might include how much they’ve paid, which bank they’ve paid it into, etc. Typically, what then happens is that this message will go onto some messaging infrastructure.
That could be a message bus in Azure, like Azure Service Bus, or it could be an event stream, such as Apache Kafka or an Event Hub, or it could just be like an Event Grid. Depending on the design requirements, there is some kind of messaging infrastructure that captures that event. The key thing then is that there might be other systems that need to be informed. These are the subscribers in a publisher-subscriber model.
A publisher publishes an event, and a subscriber subscribes to that event. In other words, they are interested in what happens over there. And that is the essence of event-driven architecture. For example, I’ve received an order from a customer. The warehouse down here, which might be your warehouse management system, says, “Oh, I’ve shipped that.” Later on, the warehouse management system might then say, “Okay, I’ve shipped that order,” which can get published back onto your message bus. Another system, like your CRM, might then say, “Oh, I’d better inform the customer by sending them an SMS that their order has shipped.” This way, we can start to chain together sequences of events: if this happens, then do this, and when that happens, other things can follow. The advantage of being in an event-based infrastructure and architecture is that we only need to do simple, discrete steps that do one thing at a time.
This approach means you don’t have to create a huge monolith. You can actually make little discrete bits of logic that happen at any one time, making it very efficient and effective. We can deliver value incrementally and rapidly. And that’s the basics of an event-driven architecture.