You probably don't need event-driven architecture
A blog post argues event-driven architecture is often overused and adds unnecessary complexity. It recommends simpler patterns like request-response or task queues for most applications, advising adoption only when clearly needed.
Background
- **Event-driven architecture (EDA)** is a software design pattern where services communicate by emitting and reacting to "events" (e.g., "order placed"), rather than making direct request-response calls. It can add complexity, latency, and debugging difficulty.
- **Domain events** are a lighter, narrower concept: they record that something meaningful happened *within* a single bounded context (e.g., a microservice). They don't imply cross-service messaging or an event bus.
- Many teams reflexively adopt full EDA (using tools like Kafka, RabbitMQ, or event buses) when they only need simple domain events or plain function calls. This over-engineering introduces operational overhead, eventual consistency headaches, and makes code harder to reason about.
- The article argues that the default should be synchronous, explicit code. Event-driven infrastructure should be adopted only when there is a concrete, measurable need — not because it's trendy or feels "scalable."