What Is Event-Driven Architecture? What It Is and Why It Matters

Some apps feel like they just get you. Like, how the heck does Netflix recommend exactly what you want to watch next? What else does it know about you? Are your intrusive thoughts even safe? Relax. You can breathe now. No one’s really watching you. It’s just event-driven architecture (EDA) working behind the scenes.

Event-driven architecture describes a system that is designed to react to “events.” An event is a change in state, which could be something as simple as a user clicking a button.

If you’re reading this article, it’s because you clicked on it. That, right there, is an event. Similarly, my keyboard “listened” to every tap as I wrote this article. Each tap was an event. Without further ado, let’s start with the basics.

EDA is a system design approach that’s all about — you got that right — events. But I don’t mean the physical events we attend with friends or family. By “event,” I mean any change in state or action.

The state is how tech bros describe the condition of data or a web application at a specific time.

When you click on an “Add to Cart” button, you probably think of that as shopping. To the system, that’s an event. EDA listens to events and responds in real time. That’s how it makes the process feel seamless and near-instant.

I must mention that EDA differs from traditional architectures. Here’s how:

Traditional architectures usually work in a more linear, step-by-step way. Step one has to be completed for the system to even think of step two. Step three is out of the question unless the system completes step two.

For perspective, in a traditional setup, the system:

1. collects customer’s information;
2. processes a customer’s order;
3. sends an email confirmation to the customer;
4. notifies the seller; and then
5. updates the inventory.

Sounds pretty straightforward, right? The only issue here is that only one step happens at a time. That kind of slows things down.

In EDA, these actions can happen independently and simultaneously. And the best part is that they’re all triggered by the same event (a button click, for example). This asynchronous flow is what makes EDA faster and more efficient.

That also explains why it’s mostly preferred when building responsive, scalable, and flexible systems.

Imagine a food delivery app like DoorDash or Uber Eats. When you place an order, the app:

1. immediately notifies the restaurant;
2. updates the delivery driver about the order you’ve just placed; and then
3. sends the customer a confirmation.

All these processes happen simultaneously. For this reason, EDA suits modern apps that need to handle high volumes of activity without compromising speed and reliability.

We’ve seen that events are occurrences or changes in a system’s state. They act as the triggers for actions within event-driven architecture.

EDA has three core components. These include:

• Event Producers: These are the things you interact with. The user interface of your website or application or an Internet of Things device such as an Apple Watch are some good examples of event producers. It’s through your interactions with them that they’re able to “produce” these events for consumers.
• Event Routers: After producing the events I’ve mentioned above, producers usually don’t know what to do with the info they’ve generated. That’s where event routers come into the picture as middlemen in EDA. Their job is to take events from the producers (the ones creating the events) and “route” them to the right consumers. Kafka and RabbitMQ are some good examples of event routers.
• Event Consumers: They are the systems or services that “consume” these events. That’s to say, they process and respond to events. Consumers handle tasks like updating a database, triggering real-time updates, or even sending a notification.

EDA makes sure that different parts of a system don’t depend on each other. This makes things easier to manage and fix if something changes.

Now let’s look at the four main types of EDAs. I’ll break each one down with examples.

Simple Event Notification

In this type, events only signal that something has happened. That’s all the info they have. Nothing else.

It’s like a simple “ping” to let another system know a task is done. For context, I’m writing this article while scanning my computer for potential viruses in the background. When the scan is complete, I’ll get a simple event notification about it.

Event-Carried State Transfer

Here, events carry all the important data a consumer needs to act. I’ll give you an example of an eCommerce site like Amazon.com.

When I place an order, that action is an event. It carries details like my info (name, email, address, etc), product details, and payment confirmation. That way, Amazon.com won’t need to ask:

“Thanks for your order, but what’s your name and address?”

And that’s because the event fetched all the information Amazon wanted to know about me.

Event Sourcing

As the name implies, this one “sources” events. In other words, it keeps a record of every change in a system as a series of events. The objective here is to create a complete history of what’s going on in that system.

Shopify’s order dashboard is probably the best example I can think of. It tracks every item added, sold, or returned.

Many positive things can happen when systems process events using the EDA technique. I’ll share a few examples below.

Asynchronous Communication

Event-driven systems let components work independently. They don’t have to wait for each other in order to accomplish what they’re supposed to.

This sense of independence is what makes EDA faster and more efficient than the traditional alternatives we looked at earlier.

Check this out:

Shopify’s payment system processes transactions. At the same time, the inventory system updates stock levels.

See what I mean?

The non-blocking setup makes sure that there are no delays, even during peak traffic.

Scalability

EDA also scales producers and consumers dynamically.

That can really save the day when your website or app experiences high traffic.

A ticket booking system like Ticket Master, for example, can handle thousands of users attempting to book tickets at once.

All the system needs to do is add new instances of consumers to process the influx of requests. That way, the system won’t crash.

Real-Time Responsiveness

Some systems are designed to react instantly to changes.

Think of a stock trading platform as an example.

You want it to be able to update prices and execute trades in milliseconds.

That’s because any instance of downtime is bad for trading. I’m not even a stock trader, but I know that accuracy is key here.

The same applies to live chat apps. No one likes delayed live chats. It’s the 21st century, for crying out loud!

Resilience

With EDA, failure isn’t tolerated; it’s isolated. This isolation ensures that a single service’s downtime doesn’t bring the whole house down.

Uber, for instance, might have technical issues with its notification service. But the booking process would still work.

That’s because the app can isolate whatever problems the notification service is experiencing.

Or better still, you may argue with your partner, but the argument doesn’t stop you from loving them. I hope that’s even more relatable!

Flexibility

EDA also makes it easy to update or add new features.

And the best part of it all is that you won’t have to rewrite the entire codebase.

For instance, if I’m a delivery driver, my job is to deliver what YOU ordered, not prepare it. I shouldn’t have to deal with an instruction like:

“Make sure the onion soup has no onions in it.”

I feel like that should be an update DoorDash needs to implement on its app. It’ll keep instructions for delivery drivers separate from those meant for the restaurant.

And if they ever decide to make such an update, they won’t need to rewrite the entire code. That’s another score for EDA.

EDA has some challenges and considerations that are worth knowing about. Let’s take a look.

Complexity in Design

When you have different features operating independently of each other, designing them becomes even more complex. That’s because you’re dealing with multiple distributed components.

And that’s not all — you must set up these events in such a way that they are consistent and correct across these components. To achieve that, you’ll need to plan carefully and also have a strong infrastructure to work with.

Latency and Reliability Concerns

Event transmission can sometimes experience delays or even message loss. This mostly happens due to network issues or failures in the messaging system.

And when it does, time-sensitive systems like live updates or notifications are usually among the most impacted.

Monitoring and Debugging

Tracing events across multiple services is difficult. This is especially true when something goes wrong with the system.

Knowing where to start, sometimes, is in itself another challenge. That explains why troubleshooting these problems usually requires specialized tools and expertise.

Event Duplication or Loss

An event might get lost on its way or show up more than once. Imagine sending a text, and your friend either doesn’t get it or gets it twice. I don’t even have to imagine it; I experience it every time I visit my grandparents in the countryside.

Cave divers have better cellphone reception, I promise you.

And when it stabilizes, all the texts I’ve been attempting to send finally get delivered, sometimes more than once.

That’s the kind of problem I’m trying to bring to your attention. To avoid this, systems need to be smart enough to handle duplicates without freaking out. A good idea would be to ignore repeated messages.

And to deal with the issue of event loss, they can use tools that double-check everything arrives safely.

When it comes to event-driven architecture, the tools you use matter. And I mean by a lot.

To improve your understanding of EDA, let’s now discuss some real-life examples of this architecture across different industries.

• eCommerce: When someone buys a product on Amazon.com, for instance, the inventory updates in real time to show “only 1 left in stock.” This update makes sure that no one else orders the same item.
• Financial Services: Suppose someone uses your credit card in another country. In that case, the system can flag it immediately and send you an alert.
• IoT and Smart Devices: Take a smart doorbell like Ring, for example. It sends a real-time alert to your phone when someone’s at your door.
• Gaming: Fortnite uses real-time systems to pair players of similar skill levels and update rankings instantly after each match.
• Healthcare: When a patient’s heart rate drops suddenly, the system sends an alert to the medical team. This could potentially save lives.

The more you look at these examples, the more you’ll realize just how EDA is woven into the fabric of our day-to-day lives.

Remember the potential challenges we discussed earlier? Most are solvable. Here are some tips to consider.

Start Small and Iterate

Don’t try to revamp everything at once. If something goes wrong, you don’t want it damaging the entire system. A smarter way would be to begin with a few important services. If you’re working on an eCommerce app, for instance, you may want to add things like notifications or order processing.

Once you’ve made sure that they’re working as they should, you can then expand as you gain confidence.

Ensure Event Idempotency

Make sure the system processes events only once. This will help solve the issue of duplicate events being sent, like the text messages I referenced earlier. You see, every duplicate event the system has to process requires some form of resources. We’re talking about memory, storage, processing power, and the like.

So it’s important to make sure you’ve designed the system in such a way that it only processes events only once. This should be the case even if the system sends the same event multiple times.

If it’s a payment processing system, and you click the “Buy Now” button twice, it should only charge you once. That’s because the system should be smart enough to realize that the second client was likely unintentional.

Use Schema Registries

Keep your events organized with a schema registry. This is just a techy way of saying that the events should follow a pre-determined marking scheme.

For example, you can decide that all events should provide the userID, timestamp, and eventType. This ensures all events follow the same structure. Spotify is a good example of a schema registry in real life.

A schema registry is a framework that describes how your data should be formatted.

When I’m playing a song, that action alone creates an event with details like the song title, artist, and play timestamp. Now imagine what could happen without a schema registry.

One development team might send this data with a field called songName. Then another team clocks in and calls it trackTitle. The third team comes in and decides to name it songTitle. Next thing you know, the app isn’t functioning as it should.

When you have a schema registry, every developer working on this app will use songName and stick to the same structure. That way, every service connected to the app, such as analytics or recommendations, will be able to process it.

Invest in Monitoring Tools

You need good visibility into how events flow. That’s where tools for tracing and logging, like Datadog or ELK Stack, come in. You can use such tools to track issues and analyze performance in real time. That also makes troubleshooting issues much easier.

Choose the Right Tools

I must tell you that not every tool you come across will work for you. Rather, you require only those that fit your business needs. If you need real-time data streams, consider Kafka. For serverless event handling, AWS Lambda might be your go-to.

These are just but a few examples. The bottom line here is that you should always align your stack with what you’re building.

That sums up the basics of an event-driven architecture. Four things to keep in mind here: it’s powerful, flexible, scalable, and responsive.

And it’s everywhere. You’ll find it in real-time apps, eCommerce, gaming, IoT, and just about anything else.

But as you’ve seen throughout this article, how you implement this architecture is what matters the most. It can be a solution or a problem, depending on how you use it.

Consider starting small, focusing on best practices like idempotency and monitoring to unlock its full potential.