What is event-driven architecture?

Event-driven architecture is often referred to as “asynchronous” communication. This means that the sender and recipient don’t have to wait for each other to move onto their next task. Systems are not dependent on that one message. For instance, a telephone call is considered synchronous or more along the lines of the traditional “request/response” architecture. Someone calls you and asks you to do something, the requestor waits while the responder completes the task, and then both parties hang up. An asynchronous example would be text messaging. You send a message and in some cases, you don't even know who you are sending it to or if anyone’s listening, but you are not waiting for a response.

The evolution of event-driven architecture

Over the past few years, there has been a movement from focusing on data at rest (service oriented architecture) to focusing on events (event-driven architecture). We are moving from accumulating data and data lakes to focus on data in flight and keeping track of it while it's moving from place to place. Traditionally, most systems operate in what you could think of as the data centric model where the data is the source of truth. The shift to event-driven architecture means moving from a data centric model to an event centric model. In the event-driven model, data is still important, but the events become the most important component. Whereas in the service oriented model, the highest priority was to make sure you don't lose any data. With event-driven architecture, the priority is to make sure you respond to events as they happen. Because there's a law of diminishing returns when it comes to events, the older they get, the less valuable they are. However, today, service oriented architecture and event-driven architecture are often used together.

Event-driven architecture often uses a log analogy of keeping track of things. Analysts talk about events as immutable things that happened. And if you want to figure out what happened in the past, you can go back and replay the log. Whereas in the data centric model, you're focused mainly on the state of the data as it is right now. And then the last analogy analysts use when describing the difference between data-centric and event-centric architectures is they often compare them between an information repository and a nervous system that carries messages around the enterprise.

When using an event-driven architecture you have event producers that generate and send event notifications and you may have one or more consumers of an event, where the receiving of the event triggers processing logic. For example, let's say Netflix has just uploaded a new movie. There could be several applications listening or waiting for that notification which then trigger their own internal systems to publish their own information about that event to their users. This differs from traditional request-reply messaging in that applications are still running and even though they may be listening for this event, they are not paralyzed while waiting for it. And, they are able to respond when the message is published. Thus, many services can be running in parallel.

What is an event?

An event is defined as a change of state of some key business system. For instance, somebody buys a product, someone else checks in for a flight or a bus is late arriving somewhere. And if one thinks about it, events exist everywhere and are constantly happening, no matter what industry. They are pervasive across any business. This includes anything that creates a message by being produced, published, detected, or consumed is considered an event. The event is separate from the message, because while the event is the occurrence, the message is the traveling notification that relays the occurrence. In event-driven architecture, an event will likely trigger one or more actions or processes in response to its occurrence. An example of an event might include:

• Request to reset a password
• A package arrived was delivered to its destination
• A grocery warehouse updates its inventory
• An unauthorized access attempt was denied

Each of these events is likely to trigger one or more actions or processes in response. One response might be simply to log the event for monitoring purposes. Others might be:

• An email to reset the password is sent to the customer
• The sales ticket is closed
• An order for more lettuce (or whatever materials are running low) is placed
• An account is locked and security personnel are notified

With event-driven architecture, when an event notification is sent, the system captures that something happened like a change in state has occurred and waits to send the reply to whoever requests it, whenever they request it. The application that received that message can either respond or wait to respond until the change in state has occurred that it is waiting for.

Applications built around an event-driven architecture enable more agile, scalable, contextual, and responsive digital business applications.

How does event-driven architecture work?

The components of an event-driven architecture can include three parts: producer, consumer, broker. The broker can be optional, particularly when you have a single producer and a single consumer that are in direct communication with each other and the producer just sends the events to the consumer. An example would be a producer that is sending only to a database or data warehouse so the events are collected and stored for analysis. Most commonly in enterprises, you have multiple sources sending out all types of events with one or more consumers interested in some or all of those events.

Let’s look at an example. If you are a retailer, you might be collecting all of the purchases that are happening at all of your stores all over the world. You are feeding them into your event-driven architecture that is watching for fraud, sending them to a credit card processor or whatever actions need to happen next. For a manufacturer, you have all kinds of data coming off your equipment that is telling you facts like temperature and pressure so you can monitor these events in real time and take actions like predict failures or schedule maintenance, depending on what the data is telling you.