Event‑Driven Architecture for Reactive Systems
Key Points
- The Reactive Manifesto defines the core principles for modern system design: asynchronous, message‑driven communication that is scalable, resilient, and ultimately leads to responsive, maintainable, and extensible applications.
- An “event” is an immutable statement of fact about something that has already happened, serving as the basic unit of information in event‑driven architectures.
- In a traditional messaging model, services send targeted, often conversational messages directly to one another (e.g., checkout → inventory, shipping, contact), requiring the producer to know each consumer.
- Event‑driven designs decouple producers from consumers by publishing events without specifying who will consume them, allowing any interested service to subscribe and react independently.
- This decoupling enables real‑time user interactions, plug‑in microservices, and flexible streaming/data analytics, while supporting the scalability and resilience goals of the Reactive Manifesto.
Full Transcript
# Event‑Driven Architecture for Reactive Systems **Source:** [https://www.youtube.com/watch?v=o2HJCGcYwoU](https://www.youtube.com/watch?v=o2HJCGcYwoU) **Duration:** 00:12:09 ## Summary - The Reactive Manifesto defines the core principles for modern system design: asynchronous, message‑driven communication that is scalable, resilient, and ultimately leads to responsive, maintainable, and extensible applications. - An “event” is an immutable statement of fact about something that has already happened, serving as the basic unit of information in event‑driven architectures. - In a traditional messaging model, services send targeted, often conversational messages directly to one another (e.g., checkout → inventory, shipping, contact), requiring the producer to know each consumer. - Event‑driven designs decouple producers from consumers by publishing events without specifying who will consume them, allowing any interested service to subscribe and react independently. - This decoupling enables real‑time user interactions, plug‑in microservices, and flexible streaming/data analytics, while supporting the scalability and resilience goals of the Reactive Manifesto. ## Sections - [00:00:00](https://www.youtube.com/watch?v=o2HJCGcYwoU&t=0s) **Reactive Manifesto Foundations for Event‑Driven Systems** - Whitney explains how the Reactive Manifesto’s core principles—message‑driven, scalable, resilient, responsive, maintainable, and extensible—shape the design of event‑driven architectures that enable real‑time user interactions, pluggable microservices, and extensible streaming analytics. ## Full Transcript
What are event-driven architectures? And how can they enable real-time user interactions, pluggable
microservices, and extensible streaming and data analytics? My name is Whitney, I'm on the Cloud
team here at IBM. Before I dig in on event driven architecture, specifically I'd like to talk about
system design, more generally and specifically the reactive manifesto. The reactive manifesto
is a set of community-driven guidelines that are intended to give a cohesive approach to systems
design. So, at the core of the reactant manifesto we have, we want our system to be message driven.
And so, specifically asynchronous messaging.
And then also, we want our our system design to be scalable,
and we want it to be resilient.
So this implies distributed systems or Kubernetes. So by scalable we mean that we want the
hardware used to expand as the workload expands and contract as the workload contracts
and by resilient we mean we we don't want any single point of failure
and if the system does fail we want it to be able to tolerate tolerate that elegantly so with this
foundation in place we should be able to build a system that is responsive responsive is the value
on top of that we can expect a system that is maintainable
so it means it's easy to change easy to fix a bug or do an update and we want one that is extensible
so we should be able to expand the system easily
so now that we have the core of what we want our systems designed to look like
now let's talk about let's level set here and talk about like what is an event
so an event is a statement of fact an immutable statement of fact about something that happened
in the past so let's give that some context we'll talk about a retail application
so a retail application has a checkout service
and that checkout service is going to want to communicate with an inventory service
a shipping service and a contact service
so with the messaging model if the inventory wants to know what the checkout is doing the checkout
will send a message directly to inventory to let the inventory know a checkout happen
and another one directly to shipping and directly to contact so with messaging we have targeted
delivery um not only that but inventory can maybe send a message back to
checkout it can be a conversational delivery conversational messaging
and then finally let's talk about where that message lives before it's sent it's it's
lives on the host service or on the producing service when it's received it lives on the um
it lives on the host service until it's received by the consuming service or in the case of a
message broker it might sit on a machine in between but regardless the the data persistence is
transient
now let's compare that to eventing so if our checkout service is producing events
it's producing an event every time a checkout happens without any concern to which service
is consuming that and so with that we have a system that's highly scalable so we have um
three services here interested in the checkout but even if we expand it to a hundred services
listening to check out that wouldn't affect what the checkout service is doing in any way
not only that when we have all the checkouts in a row we come up with an event log
and it can be replayable so we have a stream history
and a history of everything that that every checkout event that has happened
and then our data persistence depending on how the cluster is set up it can be set up to be immutable
it can be there forever as long as you have the physical hardware to back it up so we have um
instead of having transient data persistent so we have uh permanent or possibly permanent
not immutable but permanent data persistence e and t um so this is the foundation of our event driven
architecture so we have a resilient a reactive responsive system design and then that message
driven element is is event messaging specifically so when we go into our proper event design the
first thing we're going to consider are our event producers so we might have a web application
that produces events and we might have a a mobile application
and let's say we also have an edge device that's producing events so uh internet of things device
and all of these are producing events into our system so
so this piece of the system here that has all the events running through it
this is called the event backbone
so what does this system enable
well first of all we have our event logs being produced by all the producing applications
so the event logs can do a few things first it can trigger an action so if we have an internet
of things device let's say our internet of things device is a robot vacuum cleaner and when we turn
on that robot vacuum cleaner it spins up a pod on the infrastructure and that pod is a function
as a service so function as a service is a modular piece of code often associated with an edge device
that doesn't exist on a server on the server until it is turned on and that's when it is spun up so
that's called serverless function as a service is sits on top of serverless infrastructure
but the point is that event triggers an action of the with the robot vacuum cleaner to spin up
bounce all around the house make everything squeaky clean and then when the function is
finished running it powers down and perhaps that'll cause our function as a service to send
another event back into the system to let it know that the the function is complete
another cool thing about the event log is it can be used to help optimize and customize data
persistence so if our web application is our maybe it's our retail application that we talked about
before and it's doing a stream of checkout events well our inventory service can be reading from
that and it's keeping track of a local data store that's keeping track of the inventory
so our inventory service will consume from that data stream from the web application it'll
modify the local data and then it'll produce again into the event backbone and so this new
stream is giving the most current inventory to any other application in the system that
wants to consume from it and so while we're talking about data another thing that happens
we can save all of the data that comes through the system so all the raw data or all of the transform
data here at the end once it goes through the system we'll save it all in a huge data lake
and this is what's going to power really data-heavy applications
like ai for example and the data lake is accessible from anywhere in the system
that any service that you let consume from it
so another thing that our event-driven architectures can enable are a stream processing
so this is built on top of the apache kafka streams api
so let's say that our mobile app is producing let's say it's a music streaming service and
every time let's say up until your in your whole life up until this point you've been listening to
only miley cyrus and britney spears but today you decide you know what i want to see what jay-z is
about and you turn jay-z on well immediately your streaming app is showing you kanye west
and lauren hill and giving you ideas about what you might want to listen to next so that stream
processing is a really powerful and what gives the gives real-time calculations like if it's a
ride share app you um that you know exactly how far away your ride is but it can also be used to
implement business rules and business policies and it can be used for real-time analytics
and then let's also talk about with our system the communications layer
so specifically it's called pub sub communication
for publish subscribe so we could have any microservice a containerized microservice
and just like we talked about before with it being extensible we can very easily plug it into we can
write a new microservice and plug it into our system and immediately have it start consuming
from any stream and producing to a new stream or even producing to a stream that already exists
and none of the other applications need to be concerned with it at all so it's
highly plugable not only that but because of the stream history we talked about before
when you plug it into the system you don't have to have it start consuming from right this moment
it can be consuming from as long as from the beginning of your application if you've been
saving your stream history for that long so as long as that stream history persists when
you plug in a new system it can consume from either the old data or can be consumed from
the present moment so with that we talked about the major benefits of event driven architecture
that sit on top of the reactive manifesto ideas for system design with eventing at its core