A decade ago, every problem was getting solved with microservices. Today, every problem is getting solved with events. Kafka clusters sprout like mushrooms after rain. RabbitMQ instances multiply in the dark. Sagas and event sourcing patterns get applied to workflows that could have been handled with a database transaction and a background worker.
The pattern feels painfully familiar. The industry has found a new hammer, and suddenly every problem looks like a nail.
The Déjà Vu Is Real
The parallels between the microservices craze of the 2010s and today’s event-driven architecture (EDA) fever are striking. Back then, teams ripped apart perfectly functional monoliths because “microservices” was the answer to everything. Today, teams introduce Kafka, RabbitMQ, Redis Streams, sagas, and event sourcing for workflows that could have been handled with a database transaction and a background worker.
The result? Systems that introduce eventual consistency, operational complexity, debugging challenges, and idempotency concerns, all for problems that didn’t exist before the architecture change.
But here’s the thing: event-driven architectures solve real problems. The question isn’t whether EDA is useful, it’s whether we’ve stopped thinking critically about when it’s actually justified.
Where Event-Driven Architecture Actually Shines
After 30 years of dealing with the fragility of shared database integration patterns and the problems that arise from batch-based and ETL architectures, experienced architects recognize that EDA offers a genuinely more resilient approach to integrating disparate systems.
Databases are not APIs. When teams design systems around database schemas instead of shared contracts, they create coupling that’s harder to untangle than any event-driven system’s complexity. Events force you to think about what actually matters between services, the business facts, not the internal representation.
Domains with genuine domain overlap between workloads benefit enormously from event-driven patterns. When you have multiple independent services that need to react to the same business event, inventory needs to know about an order, shipping needs to create a label, and marketing needs to update a customer profile, events decouple the publisher from the consumers in a way that HTTP calls never can.
The producer doesn’t care who’s consuming. That’s real value.
The Silent Wake-Up Call Nobody Talks About
Here’s where the story gets interesting. One engineer’s experience building an AI agent scheduler reveals something uncomfortable about our collective obsession with event-driven design.
Their system needed to wake expensive agents, each backed by an LLM, each call costing real money, each taking real seconds. The “obvious” architecture was event-driven: whenever a message arrived or a dependency finished, fire an event and wake the agent instantly. Reacting the moment something happens is obviously better, right?
The result was a growing pile of patches. Signals arrived in bursts, so they added something to squash a flurry into one wake instead of ten. An agent could get stuck waking itself, so they added a rate limit. An agent’s own actions echoed back as new signals and woke it again, so they added a filter to ignore its own echo.
Every single patch was a sensible fix to a real problem. And that’s the trap.
The system eventually needed a watchdog. If an agent woke a few times in a row and found nothing to do, the watchdog would step in and calm it down, because the event system could fire an agent at nothing, over and over, burning money on calls that did nothing. They had written a program whose whole job was to babysit their scheduler and protect them from it.
You don’t write that for a system that works.
The Ugly Truth: Edge-Triggered vs. Level-Triggered
What the engineer discovered is something system designers have known for decades but keep forgetting: there’s a fundamental difference between edge-triggered and level-triggered systems.
Reacting the moment something changes is edge-triggered. You catch the instant of change, and if you miss it, it’s gone. That’s exactly the lost wake-up that plagued the scheduler.
Checking the current state on a beat is level-triggered. Miss a beat and the state is still there next time. The most trusted infrastructure most of us run, Kubernetes, works this way. A Kubernetes controller does watch for changes, for speed, but it doesn’t trust the watch. It reconciles. On a recurring sync it reads how things actually are against how they should be and nudges them closer. The watch is a hint. The reconcile loop is what keeps it correct.
The thing too many architects are too clever to reach for is the thing the pros built on from the start: a dumb loop on a timer.
When Polling Beats Events
The engineer’s solution was brutally simple. They deleted the event-driven path entirely and dropped in a loop. Every sixty seconds it wakes up, walks the agents, asks each one “anything to do here?”, and if so, does it. That’s the whole scheduler.
The events didn’t go away. They stopped being triggers and became data. Before, a signal fired and something reacted right then. Now a signal gets written to a list and waits, and the next time the loop comes around it reads the list and handles whatever’s there.
The machinery evaporated. The burst-squasher, the rate limit, the echo filter, the watchdog, the special cases, the bookkeeping tracking who was owed a wake, all deleted, because every piece of it only existed to survive reacting in real time, and they’d stopped reacting in real time.
The Four Axes That Matter
The reason reacting instantly falls apart for certain workloads comes down to four axes, and understanding them is the difference between good architecture and cargo-culting patterns.
Cost of reaction. For a web server, a wasted reaction costs nothing. A request is cheap, brings its own context, and the whole game is to answer each one now. For an expensive LLM call or a slow batch job, a wasted wake-up is a line item, not a rounding error.
Concurrency model. If multiple reactions can write to the same state simultaneously, you have races. If each agent has one running transcript that every wake writes onto, firing two at once produces replies tangled into one history that makes sense to nobody.
Latency tolerance. When nobody is watching a spinner for a background agent, a minute of lag before it starts is invisible. Shaving a delay to zero that nobody can perceive is wasted effort.
Caching behavior. The big model providers cache the front of your prompt now, the standing instructions plus the conversation so far. A call that starts with identical text to the last one is billed at a fraction for that shared part. Reacting invites a rebuild. The loop runs the agent on the same standing context wake after wake, so the front matches what you sent last time and the discount holds.
Three of those four have nothing to do with AI. Expensive, single-writer, no rush, wherever those line up, reacting to every change is the wrong reflex, whatever the work is.
The Complexity Creep Is Real
The silent failures in event-driven systems are the hardest to catch. A signal shows up for an agent whose situation has quietly changed, gets routed nowhere, and vanishes. A signal that matters gets mistaken for the agent’s own echo and dropped, so the one wake needed is the one the system ate.
These aren’t bugs in the business logic. The rules are fine. Every one lives in the gap between a signal firing and a busy, expensive system being ready for it.
The industry has produced a steady stream of war stories about this exact phenomenon. The common failure patterns in event-driven architectures are depressingly predictable, systems that were supposed to be loosely coupled end up tightly coupled through shared event schemas, deployment dependencies, and implicit ordering constraints.
The Counterargument That Matters
Having spent 30 years dealing with the fragility of “shared database” integration patterns, some architects argue forcefully that EDA is a significantly more resilient approach to integrating disparate systems. And they’re not wrong.
Databases are not APIs. When teams talk about design in terms of database schemas instead of shared contracts, they open themselves up to a world of hurt. As systems grow, products need greater flexibility in how to slice and dice information, and organizational coupling becomes a major bottleneck.
The key insight is that event-driven architecture doesn’t require microservices. You can use event-driven architecture within a monolith. You can have different boundaries, customers, orders, billing, inventory, notifications, all deployed in a single instance, using a single database, each boundary owning its particular schema.
Physical boundaries are not logical boundaries. That distinction gets lost constantly.
The Real Problem: Reverse Engineering Your Architecture
Most teams do architecture backwards. They start by thinking “we need to deploy this independently for scale.” Then because of that, they decide they have to always communicate through events or always communicate asynchronously. Then they introduce HTTP APIs everywhere, creating more network hops. After all that, they try to decide what should go where.
The right order is:
- Define logical boundaries
- Choose communication patterns
- Choose deployment model
Most people do this in reverse, and that’s how they get into trouble. Resisting architectural trends that add unnecessary complexity starts with understanding that deployment model should be the last decision, not the first.
The Hidden Costs Nobody Talks About
The infrastructure overhead of event-driven systems is staggering compared to the alternatives. A monolith might run on two application servers, one PostgreSQL database, and a cache. The “event-driven” version often requires six microservices, a Kafka cluster, six different databases, and a service mesh.
The hidden costs of loose coupling in event-driven systems compound in ways that architects rarely anticipate. The developer experience goes from “clone one repo, run Docker Compose, everything works” to “install Kafka, Zookeeper, all these databases locally, and pray the configuration aligns.”
When Events Are Genuinely Justified
Despite the cautionary tales, event-driven architectures have legitimate use cases:
Highly distributed systems with domain overlap. When you have genuinely independent services that need to react to the same business events without coupling to each other’s availability, events are the right tool.
Workloads with different scaling characteristics. When the publisher and consumer scale at different rates, or need to operate at different availability levels, asynchronous event delivery decouples their operational concerns.
Workflows that span multiple systems. When a single business process crosses organizational or system boundaries, events model the real-world flow more naturally than synchronous calls.
Audit and replay requirements. When you need a complete, immutable record of what happened and when, event sourcing provides that natively.
The question isn’t whether EDA is ever useful, it absolutely is. The question is whether it’s useful for your specific problem, or whether you’re reaching for it because it’s the trendy solution.
A Simple Litmus Test
Before adding Kafka, RabbitMQ, or any event broker to your system, ask yourself:
- Does the consumer need to know about this event immediately, or would a sixty-second delay be invisible?
- Would a polling loop with a database table work just as well?
- Have you defined your logical boundaries first, or are you leading with infrastructure decisions?
The engineers at OpenAcme discovered something valuable: the rewrite was easy. The hard part was admitting the primitive answer was right. A loop on a timer is the thing you write in your first week, and reaching for it after years of supposedly knowing better feels like losing. It isn’t. It’s boring. And boring is about the highest praise there is.
Production debugging nightmares in event-driven systems happen precisely because architects optimize for elegance over predictability. The loop doesn’t produce elegant diagrams. It doesn’t get conference talks. But it works, quietly and reliably, without a watchdog to babysit it.
The Takeaway
Event-driven architecture is not the problem. The misunderstanding is. Not everything needs to be asynchronous. Not every event is a business event. Not every boundary needs to be independently deployed. Not every event-driven system needs Kafka, microservices, six databases, and a service mesh.
Use events when they solve the right problem. Use synchronous communication when that’s what the workflow requires. Model the business process correctly. Define your logical boundaries first.
Because events can help reduce coupling, but they cannot fix bad modeling. And messaging can’t save you from bad boundaries. The same lesson applies to microservices, event-driven architecture, and whatever the next bandwagon will be.
The tool isn’t the problem. The thinking is.
