Most enterprises are built on questions.
"Has the order shipped yet?"
"Did the payment go through?"
"Is there any new customer data?"
Systems keep asking each other these questions, over and over, on schedules and polling loops. It works. But it is slow, chatty and fragile, and it gets worse every time you add another system that wants to ask the same question.
Event-driven architecture flips the model around. Instead of asking, systems announce.
Something happened. Here are the facts. Whoever cares can react.
That small shift changes a lot about how an enterprise behaves.
What Is Event-Driven Architecture?
In an event-driven architecture (EDA), components communicate by producing and consuming events.
An event is a record of something that already happened: an order was placed, a payment was received, a customer changed their address. It is a fact, written in the past tense.
There are three main roles:
- Producers publish events when something happens in their domain.
- The event broker (Kafka, Anypoint MQ, Salesforce Platform Events, a cloud event bus) receives and distributes them.
- Consumers subscribe to the events they care about and react in their own way.
The important part is what is missing from the diagram. The Order Service has no idea that Inventory, Notifications, Analytics and CRM exist. It publishes the fact and moves on.
Why Architects Care About It
Loose coupling
When producers do not know their consumers, you can add, remove or change consumers without touching the producer. In a large organization, that is the difference between a one-team change and a five-team coordination exercise.
Real-time by default
Instead of waiting for the nightly batch or the next polling cycle, consumers react within seconds. Customers notice this. So does the business.
Resilience
If the Analytics consumer is down for an hour, orders still get placed. The broker keeps the events, and Analytics catches up when it comes back. Compare that with a synchronous chain where one slow service drags everything down with it.
A natural fit for scale
Events can be partitioned, replayed and processed in parallel. High-volume domains like IoT, payments or clickstream data are almost impossible to handle well without them.
Events Are Not a Replacement for APIs
This is where I see teams go too far.
Once a team discovers events, everything starts to look like an event. But request and response still has its place. If a user is waiting on screen for an answer ("is this product in stock?"), you usually want a synchronous API call.
A simple rule I use:
- Use an API when you need an answer now.
- Use an event when you are telling others that something happened.
Most healthy architectures use both. APIs for queries and commands, events for notifications and state changes.
The Hard Parts Nobody Mentions in the Demo
Event-driven systems look elegant on a whiteboard. In production, a few things deserve serious attention.
Event design
An event is a contract. If you change its structure carelessly, you break consumers you may not even know about. Version your events, document them, and keep a schema registry or catalog.
Thin or fat events
Should the event contain only an ID ("order 123 was placed") or the full order details? Thin events keep things small but force consumers to call back for data. Fat events are convenient but can leak too much information and create hidden coupling. There is no universal answer. Decide deliberately, per domain.
Ordering and duplicates
Brokers may deliver events more than once, and not always in the order you expect. Consumers must be idempotent, meaning processing the same event twice must not cause damage, like charging a customer twice.
Observability
When a process is spread across ten consumers reacting to events, "where did this order get stuck?" becomes a genuinely difficult question. Correlation IDs, tracing and good monitoring are not optional extras. They are the price of admission.
Eventual consistency
Different systems will be briefly out of sync. The CRM might show the order a few seconds after the ERP does. The business needs to understand and accept this, and some processes will need explicit handling for it.
Common Patterns
A few patterns come up again and again:
- Publish and subscribe: one event, many independent consumers.
- Event notification: a lightweight signal that something changed.
- Event-carried state transfer: the event carries enough data that consumers do not need to call back.
- Event sourcing: the event log itself becomes the source of truth, and current state is rebuilt from it.
- Saga: a long-running business process coordinated through a series of events, with compensating actions when something fails.
Most organizations only need the first three. Event sourcing and sagas are powerful but add real complexity, so use them when the problem genuinely demands it.
EDA and AI Agents
Events are becoming even more important as AI agents enter the enterprise.
An agent that only acts when a human prompts it is limited. An agent that can subscribe to business events ("a high-value order was cancelled", "a VIP customer raised a complaint") can act proactively, within guardrails. Event streams are quickly becoming the nervous system that intelligent applications plug into.
Where to Start
If your organization is new to EDA:
- Pick one domain where multiple systems need the same change, like order status.
- Define a small set of well-named business events with clear schemas.
- Introduce a broker that fits your landscape, rather than the trendiest one.
- Move one or two consumers from polling to subscribing, and measure the difference.
- Invest early in monitoring and an event catalog.
Final Thought
Event-driven architecture is less about technology and more about a mindset:
stop asking systems what changed, and let them tell you.
When an enterprise starts to work that way, it becomes faster, calmer and much easier to extend.