For about a decade now, event-driven architecture (EDA) has ridden alongside microservices in the market. Kafka, RabbitMQ, AWS EventBridge, Google Pub/Sub, SNS/SQS. Every one of them is selling the same idea: services shouldn’t call each other directly, they should publish events and let listeners do the work.
Nice in theory. In practice? Some projects find it a miracle, others a complexity machine. Here’s when it’s each.
Where event-driven genuinely shines
1. Multi-consumer scenarios. When one event has four or five different consumers, EDA is the rational choice. When an order is placed:
- Email service sends a confirmation
- Analytics service writes an event
- Inventory service decrements stock
- Loyalty service calculates points
- Fraud detection runs a check
If these five services all called the order service one by one, the order service would have to know about all of them. Publishing one event is a single line, and consumers run at their own pace.
2. Async workflows. When a user hits “upload profile picture” they should get an immediate response, but in the background you still need to:
- Generate a thumbnail
- Run content moderation
- Push to the CDN
- Update the user search index
Those four steps can take three to four seconds. With events you return 200 immediately and process in the background.
3. Audit and replay. For financial or compliance-driven systems, if every state change is recorded as an event, you get an audit log natively. And when you need to “replay this event against the state from three days ago”, replay is possible.
4. Cross-service decoupling. In a product with five services, not having each service know about every other one is valuable. Systems that talk through an event hub (Kafka, EventBridge) evolve more cleanly.
Where EDA doesn’t help
1. Simple workflows with a single consumer. “When an order arrives, send an email” has one consumer. Spinning up an event hub for that is wasted effort. A direct call or a queue (SQS is enough) is fine.
2. Tight transactional requirements. Banking, inventory reservations, the all-or-nothing cases run away from event-driven models. Eventual consistency isn’t acceptable, you need a synchronous transaction.
3. Small teams. Managing event schemas, versioning events, and monitoring consumers is operational overhead. A three-person team carrying that load is inefficient.
4. Scenarios that need a real-time response. “User paid, show the confirmation now” flows lose milliseconds to event-driven hops. A synchronous API is better.
Three mistakes I see often
Mistake 1: “We do event-driven” when in reality it’s just a message queue. One consumer, no event schema, no replay, no audit log. That’s asynchronous RPC, not EDA.
Mistake 2: Sparse event payloads. You publish an event with only user_id: 123. The consumer has to call the user service every time to fetch the details. That isn’t event-driven, it’s notification. A proper event isn’t “user created”, it’s “user created, with these fields: …”.
Mistake 3: No versioning plan. Six months later the event schema changes and breaks every existing consumer. In EDA event schemas have to be versioned and evolve in a backward-compatible way.
Practical decision tree
Deciding whether to use EDA on your project:
- How many consumers will listen to this event? One is overkill, three or more is reasonable.
- Do you need event replay? For audit, debug, or migration?
- Are consumers in the same team or different teams? Different teams make EDA worth it for the communication alone.
- Is this a synchronous user action? If so, EDA is the wrong tool.
- Does the team have the operational capacity to run it? (schema registry, monitoring, alerting)
If at least three of those point to EDA, it makes sense.
Where to start
Nobody should start with Kafka. For a proper intro:
Level 1: AWS SQS + SNS. Simple queue and topic model, minimal operational overhead.
Level 2: AWS EventBridge or Google Pub/Sub. Schema registry, fan-out, filter rules.
Level 3: Kafka. Only if you genuinely need high throughput and ordered event streaming.
Not every project starts at Level 3. Levels 1 and 2 cover most use cases and are a lot lighter operationally.
Takeaway
Event-driven architecture is a strong tool but not for every project. Multi-consumer fan-out, async pipelines, and audit-log needs make it pay off. For small teams, single-consumer flows, and tightly transactional work it’s unnecessary complexity.
Make the call on real need, not on fashion. How many consumers, how much decoupling, how much replay you really need. Those answers draw the architecture.