Event-Driven vs Message-Driven: You Have a Message Broker, but You're Not Event-Driven Yet

Home > Blog > Event-Driven Integration

A lot of enterprise teams think they’ve made the leap to event-driven architecture (EDA) just because they’ve deployed a message broker. They have topics, producers, consumers, maybe even a schema registry. The sprint review slide says “migrated to event-driven architecture.” The Confluence page gets a green checkmark.

A message broker is the first brick – it is not the house.

Having bricks doesn’t make you an architect, and having a message or event broker doesn’t make your organization event-driven. You have the raw material. The blueprint is a different conversation: the design thinking, the shared vocabulary, the governance layer that turns a pile of infrastructure into something the rest of your organization can actually build on.

This article covers the difference between messaging and genuine EDA, why Apache Kafka became a household name while EDA stayed obscure, and how to use tools like Solace Event Portal to close the gap and bring every other business vertical along with you.

If you’ve ever searched event-driven architecture vs message-driven architecture, the short answer is that they are not alternatives — one is the layer the other is built on — with this piece I’ll explain why that distinction changes what you build.

What Is Message-Driven Architecture?

Message-driven architecture is the transport layer, and it is broader than most comparisons admit. It spans point-to-point message queues, publish-subscribe topics, request-reply, and fan-out, and across all of them the broker’s job is reliable delivery: ordering, retries, acknowledgements. A point-to-point queue is message-based communication at its most direct, and for request-style work it is exactly the right tool. But point-to-point is one pattern inside messaging, not the whole category.

What Is an Event-Driven System?

An event-driven system is a design discipline built on the publish-subscribe pattern of messaging, not an alternative to messaging. A producer publishes a fact that has already happened and makes no assumption about who cares, so multiple consumers can each subscribe and process the event independently. Nothing is addressed to anyone in particular, and that is precisely what produces loosely coupled systems instead of a chain of dependencies. Every event-driven system is therefore message-driven; the reverse is not true.

Every Event-Driven System Is Message-Driven: The Three Layers

Here’s a framework that clears up most of the confusion. Every event-driven system has three distinct layers:

What — The business logic layer: what events exist, what they mean, who owns them, how other systems should react to them. This is EDA.
How — The messaging guarantees: delivery order, at-least-once vs. exactly-once, idempotency, error handling.
With what — The implementation: your broker, your protocol, your cloud service.

The failure mode that produces “fake EDA” is starting at layer three and declaring victory at layer one. You picked a technology. You have topics. You have consumers. You have not, yet, done EDA.

Most teams never make it back up to layer one. It eventually bites them when a schema change cascades, teams build duplicate pipelines nobody knew about, or a new business unit wants to plug in and has no idea what’s flowing where.

Command vs Event at a Glance

Dimension	Command	Event
Addressing	One named addressee	No addressee; an audience subscribes
Coupling	The sender depends on the receiver acting	The producer does not know who consumes
Who decides what happens next	The sender, by naming the action	Each consumer, by choosing to subscribe
Adding a new consumer	Usually a change on the sending side	Self-service subscription, producer untouched
Failure mode	A distributed monolith: a broker with no decoupling	Undocumented topic sprawl with no governance

The Four Patterns of Event-Driven Architecture

Martin Fowler, one of the most widely read voices in software architecture, identified four distinct patterns that people routinely conflate when they say “event-driven” — first in his 2017 blog post “What do you mean by ‘Event-Driven’?” and the talk that accompanied it. They’re worth naming, because confusing them is how projects end up architecturally nowhere:

Event Notification: A system announces a state change and doesn’t care what happens next. CustomerAddressChanged goes out. The Email Service reacts. The Fraud team reacts. Multiple consumers, one announcement, and the source system is done. Nobody calls back. Learn more.
Event-Carried State Transfer (ECST): The event carries enough data that consumers never need to call back for more. A CustomerProfileUpdated event includes the changed fields, so downstream systems update their own local copy without a follow-up query. Learn more.
Event Sourcing: The event log is the source of truth. Current state is derived by replaying events. Think of Git: the commit history is the record, and the working tree is a projection of it. Learn more.
Command Query Responsibility Segregation (CQRS): Separate data models for reads and writes. Often combined with Event Sourcing, often misunderstood as the same thing. Learn more.

Note: You can learn more about these event sourcing patterns, and a whole lot more, in my colleague Giri’s Ultimate Guide to EDA Patterns.

These are architecturally different. Using Kafka with durable topic retention is not Event Sourcing. Calling a downstream service via a message queue is not Event Notification. Fowler himself has noted that projects claiming failure with Event Sourcing often turn out to have been confused about which pattern they were actually using.

The Real Axis: Command vs Event

The most common anti-pattern: your OrderCreated event that only ever goes to the Fulfillment Service, which is expected to pick the order and nothing else meaningful happens with it. That’s a command wearing an event’s jacket. The producer still depends on the consumer’s behavior. You’ve added a broker without adding decoupling. That’s a distributed monolith in a fancy coat. This is the command/event distinction in a nutshell: the command has one addressee, the event has an audience.

Real EDA inverts the thinking. The Order Service announces a fact: an order was placed. The Warehouse, the Fraud Detector, the Analytics Pipeline, the Email Service each independently decide whether that fact matters to them. If a new team wants to build a real-time ops dashboard off that same event, they subscribe. Nobody touches the Order Service. That is the architectural shift.

Why Kafka Got Famous While EDA Stayed Obscure

Apache Kafka was built at LinkedIn around 2011 to solve a real, specific problem: how do you move data between dozens of internal systems at scale without building dozens of custom pipelines? Jay Kreps’ insight was to treat data as an immutable, ordered log with durable retention which is why Kafka became the default substrate for stream processing. Genuinely elegant. It got donated to Apache, commercial services grew around it, and within a decade it was on the resume of every data engineer worth hiring.

Kafka got famous because its story is concrete and developer-centric: open-source infrastructure with benchmarks you can cite, managed services you can spin up today, a growing ecosystem of connectors. That story travels fast through conference talks and job listings.

EDA stayed obscure because it’s a design discipline, not a product. It requires domain modeling, cross-team alignment, and organizational decisions about who owns which events. None of that fits in a GitHub repo or shows up on an infrastructure cost dashboard. You can’t spin it up in an afternoon. It’s invisible until you have the vocabulary to recognize it and the tooling to make it tangible.

Kafka answers a technical need, real-time processing of high-volume data in motion, and it answers it well. EDA answers a business transformation. They are not the same question, and buying the right tool for one does not automatically get you the other.

The result: organizations with sophisticated streaming infrastructure and almost no shared understanding of the events flowing through it. A cluster with 300 topics, no documentation, and no governance is just a very fast, very expensive spreadsheet that nobody fully understands.

The Gap a Schema Registry Can’t Fill

A schema registry (like Solace’s, which is really good) ensures your event payloads are compatible at runtime. It handles serialization, deserialization, version compatibility rules, and schema governance. That work matters. Without it, producers and consumers drift apart silently and debugging becomes archaeology.

But even a well-run schema registry answers one question: what shape is this data?

It doesn’t answer questions like:

Why does this event exist?
Which business process triggers it?
Which teams subscribe to it?
What breaks downstream if you change it?
Has another team already built something similar?

Schema registries are the bricks. EDA practice requires a blueprint: something that shows you not just what pipes exist, but where they go, who put them there, and what happens if you move one. AsyncAPI sits alongside this on the specification side, giving teams a machine-readable way to describe event-driven APIs, but a spec still describes interfaces rather than telling you who already depends on them.

Solace Event Portal: The Blueprint Layer

Solace Event Portal is the design and governance layer that answers the questions a schema registry can’t. It turns event infrastructure into a shared organizational asset: a single place where architects, developers, and business domain experts can see, document, and reason about the events flowing through their systems.

Application Domains organize events by business context (Loyalty, Operations, Supply Chain) with clear ownership and access controls. Each domain is where teams design events before sharing them with the rest of the organization.
Designer gives architects a live, visual canvas of which applications publish and subscribe to which events. It stays synchronized with runtime through Solace’s discovery agents. What you see is what’s actually running today, not the diagram someone drew six months ago.
Catalog is where cross-team collaboration starts. Teams search by event name, schema field, business domain, or tag, the same way they’d use an API developer portal. When a Finance engineer discovers that OrderConfirmed already carries the fields they need, the conversation shifts from “how long to build this?” to “who do I talk to about subscribing?” — and with Solace Smart Topics, they often don’t even need to ask. Each event in the Catalog exposes its full topic address, built as a structured, multi-level descriptor of the event’s content. A new consumer can read that topic structure, craft a wildcard subscription to receive exactly the slice of data they need, and start consuming — without coordinating with the producing team at all. The producer never needs to know a new subscriber exists. That’s the self-service moment EDA is supposed to deliver, loose coupling you can actually see, and it’s what makes the Catalog more than a documentation tool.
Dependency mapping shows the blast radius of a schema change before it reaches production. Own the CustomerProfile schema and want to add a required field? Event Portal surfaces every event that references it and every application that consumes those events. You know exactly who to contact before anything breaks.
Discovery agents handle the brownfield reality. Most organizations have existing infrastructure with undocumented topics and consumer groups nobody has ever mapped. Solace Event Portal scans those environments and reverse-engineers the topology into the Catalog, giving teams a searchable, governable starting point without rebuilding from scratch.
Event API Products let teams package curated groups of events and publish them to internal or external consumers through a governed interface, without exposing raw infrastructure details. Same concept as an API developer portal, applied to real-time event streams.

The Catalog’s value isn’t replacing your documentation. It’s making documentation a natural byproduct of the work itself, kept synchronized with what’s actually running.

How to Bring the Rest of Your Organization Along

You built something real. Orders flow in real-time. Latency dropped. Coupling decreased. Almost nobody outside your team knows it happened, understands what it means, or has any reason to care.

That’s the EDA evangelism gap. It’s why successful pilots stay isolated instead of becoming the platform the whole organization builds on.

Frame it as a business moment, not a tech win

Don’t open with “we implemented an EDA.” Open with: “When a customer places an order, our fulfillment team now has what they need in under 100 milliseconds, without calling us. Here’s why that mattered during last year’s peak season.”

The architecture is supporting evidence. The business outcome is the headline.

Ask the one question that surfaces everything

Invite stakeholders from other business verticals and ask: “If you could react to any business event in real-time, with no nightly batch and no ticket to another team, what would you build?”

Supply Chain might want to know the moment a high-value shipment is flagged for delay. Finance might want P&L projections and analytics that update the instant a deal closes. Ops might want to trigger a customer notification the moment an IoT sensor crosses a threshold. Most of these teams assume the answer is “too expensive” or “not possible yet.” Show them the Catalog and let the “wait, that event already exists?” moment happen organically.

The United Airlines lesson: make the Catalog the room

United Airlines ran a workshop specifically centered around Solace Event Portal’s Catalog with teams from multiple business units. Engineers and architects who rarely worked from a shared view of the organization’s data flows opened the Catalog together for the first time. Teams that had been building custom pipelines to move data across departments discovered those events were already there: documented, governed, and ready to subscribe to. The session didn’t open with a pitch or a roadmap. It opened with a search. That format is worth stealing.

Pull up the Catalog live in a cross-departmental meeting. Search for events in your domain. Show the schemas, the producers, the consumers. When an engineer from another vertical can browse a real event and picture subscribing to it, the question moves from “what would this cost to build?” to “when can we start?” The discovery is the pitch.

Build a shared language first with the Think Event-Driven Masterclass

Vocabulary is one of the hardest parts of EDA evangelism. Solace’s Think Event-Driven Masterclass is a one- or two-day facilitated workshop that gives architects, developers, and product owners a shared mental model: Solace’s proven 6-step EDA methodology, hands-on event flow design, and a common language for talking about events, domains, and topic structures. A cross-functional team that’s been through that session together reads the Catalog demo completely differently.

Track Event Reuse and Tell that Story

Once your Catalog has events from more than one team, track how many times each event gets consumed outside its originating domain. That number is your event reuse rate. It’s a concrete, business-legible measure of the platform effect EDA creates. More reuse means fewer duplicate pipelines, fewer silent failures from undiscovered schema changes, and more value from the same infrastructure investment. Put it in architecture reviews. Tell it to leadership. It’s the metric that explains why the investment compounds over time.

That’s my conversational take on how to drive toward EDA success across your organization – our official more fully-fleshed out recommendation is an approach we call the “Think Event-Driven” methodology which you can learn about here.

Getting Started

If your organization has messaging infrastructure but hasn’t crossed into genuine EDA, here’s how to get moving:

Read up on our Think Event-Driven implementation methodology here.
Take the EDA Maturity Assessment: a free Solace tool that benchmarks your current state across six EDA dimensions and shows you where the fastest ROI is.
Get your events into Solace Event Portal: the discovery agent can scan your existing infrastructure and build a starting Catalog in hours, not weeks.
Run a cross-team Catalog session: invite two or three adjacent business verticals, open the Catalog together, ask the “what data do you wish you had?” question, and leave with actual backlog items.
Sign up for our Think Event-Driven Masterclass if you want structured guidance through the whole journey. The course , delivered by experts from our services team, gives you a facilitated path from first principles to actionable event design in a single day.

Self-Check: Are You Publishing Events or Sending Commands?

Answer these five honestly before you decide how far you have actually come:

Can a new team subscribe to one of your existing events without the producing team changing anything?
Can you name every consumer of your three busiest events?
Would a schema change next sprint surprise anyone downstream?
Does each event have a documented owner and a business meaning, not just a topic name?
Could a business stakeholder find a relevant event on their own, without asking an engineer?

Mostly “no”? You have messaging working as plumbing, which is a real achievement, but you are still moving commands rather than publishing events. That is a starting point, not a failure. The EDA Maturity Assessment scores the same question across six dimensions and shows where the fastest return sits.

Key Takeaways

Messaging is the transport layer: point-to-point message queues, publish-subscribe, request-reply, and fan-out. Its job is to get a message where it needs to go, reliably.
The two are not alternatives and not synonyms. Every event-driven system is message-driven; the reverse is not true.
Event-driven is a design discipline built on the publish-subscribe part of messaging. A producer announces a fact, and multiple consumers each process the event independently, which is what produces loosely coupled systems.
A message broker is infrastructure. EDA is the design discipline layered on top of it: shared event semantics, clear ownership, and governance.
Kafka, or any broker, gives you the “with what.” It does not give you the “what” or the “how.”
The real axis is command vs event. A command has one addressee and names the action the sender wants taken; an event has an audience and names a fact that already happened. The fastest tell is whether a new team can subscribe without the producing team changing anything.

Conclusion

The gap between “we have a message broker” and “we are event-driven” is mostly organizational, not technical. That, in the end, is what event-driven vs message-driven really comes down to. The blueprint exists, the methodology is proven, and the tooling is there.

What bridges the gap is making your events discoverable, understood, and available to every team that could create value from them. Solace Event Portal is that bridge. The Think Event-Driven methodology is the plan. The cross-team Catalog session is the moment it clicks for everyone else.

Are you at the “we have messaging, now what?” stage? Drop a comment below, or explore Solace Event Portal and the Think Event-Driven Masterclass to see how other enterprises have made the leap.

Want to see the blueprint layer running against real event flows? See the platform demo.

FAQ: Event-Driven vs Message-Driven

Is event-driven vs message-driven a choice, or a difference of layer?

Neither names an alternative to the other. Messaging is the transport layer, spanning queues, publish-subscribe, and request-reply; event-driven architecture is a design discipline built on its publish-subscribe pattern. Every event-driven system is therefore message-driven. The difference is what travels in the message: a fact with an audience, or an instruction with a named addressee.

What is the difference between a command and an event?

A command tells a specific service to do something and expects it to happen. An event states that something already happened and makes no demand of anyone. If removing the only consumer would count as a bug rather than a non-event, you published a command, whatever you named it.

Is a message broker the same as an event-driven system?

No. A message broker is the implementation layer: topics, partitions, delivery guarantees. An event-driven system adds the design layer on top, covering what each event means, who owns it, who subscribes, and what breaks when the schema changes. Brokers ship in an afternoon; that design layer does not.

Is Kafka event-driven or message-driven?

Kafka is message-driven infrastructure that is well suited to event-driven architecture. It gives you durable, ordered logs and strong stream processing primitives. It does not give you event ownership, business semantics, or governance. Kafka is necessary for many EDA designs and sufficient for none of them.

Event-Driven vs Message-Driven: You Have a Message Broker, but You’re Not Event-Driven Yet