Are You Event-Driven or Event-Based?

In the world of modern software development, you will probably have heard the terms “event-driven” and “event-based” used interchangeably. But there’s a crucial difference between these approaches that can impact how we build and communicate about our systems. In this post, I’ll break this down in a way so that you can answer the question - are you event-driven or event-based?

What Exactly Is an Event?

Before we dive into the differences, let’s start with a simple definition: an event is a notification that something has changed. It’s immutable – meaning once it happens, it can’t be changed or undone.

Think about walking into a dark room and flipping the light switch:

• When you flip the switch on, a “light switched on” event occurs
• If you want to turn off the light, you can’t “un-switch” it on
• Instead, you flip the switch again, creating a new “light switched off” event

Each of these events is irrefutable. They happened at a specific point in time, and they cannot be changed.

Event-Based vs Event-Driven: The Key Distinction

So if that’s an event, what’s the difference between being event-based and event-driven? At a high level, the difference is one of language. Whilst both event-based and event-driven systems trigger functionality using events, event-driven systems use business events to trigger business functionality.

Event-based systems use technical events, not business events.

Event-Based Systems

• Focus on technical events
• Examples include:
  • Button clicks in a UI
  • Window resize events
  • File uploads to S3
  • Database record updates
• Typically understood only by technical team members
• Implementation-focused rather than business-focused

Event-Driven Systems

• Focus on business events
• Examples include:
  • Order placed
  • Pizza boxed
  • Staff member clocked in
  • Invoice uploaded
• Understood by everyone in the organization
• Business-focused rather than implementation-focused

A Real-World Example: Pizza Restaurants

Let’s make this concrete with an example. Imagine two pizza restaurants, both building modern systems to manage their operations.

The Technical Events (Event-Based)

Both restaurants might have similar technical events:

• ButtonClicked
• S3ObjectCreated
• WindowResized
• DatabaseRecordUpdated

The Business Events (Event-Driven)

However, their business events might be quite different:

Restaurant A:

• OrderPlaced
• PizzaInOven
• OrderReady

Restaurant B:

• OrderAccepted
• PizzaPreparationStarted
• DeliveryQueued

While these events might trigger similar technical processes, they’re expressed in each business’s unique language and terminology. Many systems will have a very similar set of technical events, people are always clicking buttons and uploading files.

But different business’ have different language for talking about what it is their system does.

Why This Distinction Matters

The power of event-driven architecture isn’t just in its technical benefits (though there are many, including loose coupling and scalability). The real magic happens when your entire organization can understand and participate in discussions about how your systems work.

Consider these two scenarios:

1. Technical Event: “When an S3ObjectCreated event occurs, trigger the Lambda function.”

2. Business Event: “When an InvoiceUploaded event occurs, start the approval process.”

Which one would make more sense to your non-technical stakeholders?

Now that’s not to say you don’t need the technical events. If you’re building your application on AWS, and people are uploading files, you are almost certainly going to be reacting to S3ObjectCreated events. The key distinction is that you wouldn’t expose that S3ObjectCreated event outside of your service.

Inside the invoicing service you would reach to the S3ObjectCreated event, but you would translate that into a InvoiceFileUploaded event that you then publish for public consumption.

Downstream consumers shouldn’t care about implementation details. S3ObjectCreated is an implementation detail. This has the knock on effect of keeping your service flexible. If you decide at some point you need to switch to EFS instead of S3, you can do that without breaking downstream consumers. As long as you still publish the InvoiceFileUploaded event with the same structure you’re good.

The Communication Advantage

Event-driven architecture are a communication pattern as much as a technical pattern. They are a way of modelling the integration between systems. When your events reflect your business language:

• Business stakeholders can actively participate in technical discussions
• Requirements are clearer and more accurate
• Technical implementations better reflect business needs
• Cross-team communication improves
• System behavior becomes more predictable and understandable

Making the Shift

If you’re building systems today, consider how you can move from purely technical events to business-focused events. Ask yourself:

• Do your non-technical colleagues understand your event names?
• Do your events reflect business processes or technical implementations?
• Could a business stakeholder predict what happens when an event occurs?

Conclusion

While event-based and event-driven architectures both use events, event-driven architectures bring your business language into your technical implementation. This isn’t just about better technology – it’s about better communication, clearer requirements, and systems that actually meet you business needs.

Remember: Technical events tell you what happened in the system. Business events tell you what happened in your business. Choose the approach that helps your entire organization understand and contribute to your system’s success.