Event-Driven Architecture: Misunderstanding, Not Events, Is the Problem, Argues Derek Comartin

Many organizations adopt Event-Driven Architecture (EDA) to untangle tightly coupled systems, only to find themselves grappling with debugging nightmares, out-of-order events, duplicate retries, and painful local development experiences. Derek Comartin of codepinion.com contends that these issues, often attributed to EDA, stem from fundamental misunderstandings and misapplications rather than inherent architectural flaws. Referencing a post titled “Our event-driven architecture created more problems than it solved,” Comartin argues that while EDA offers valuable benefits like reducing temporal coupling for workflows, integrations, and scaling, its complexities are often amplified by poor design choices and a failure to correctly model business processes.

Comartin systematically debunks common complaints. Regarding “eventual consistency hell” due to compensating actions, he clarifies that external interactions (like shipping or payment processing) don’t allow simple database rollbacks, labeling the issue “workflow modeling hell.” True business events, such as OrderSubmitted or PaymentAuthorized, should drive events, not low-level CRUD operations. For performance slowdowns and perceived eventual consistency in user-facing features, Comartin stresses that not all interactions need to be asynchronous; critical user updates should be synchronous, ensuring immediate “read your own write” consistency, while events can still inform downstream systems asynchronously. He also addresses the “single point of failure” concern, noting that vital infrastructure like Kafka requires the same high availability, monitoring, and failover strategies as any database, and messaging can even enhance resilience through patterns like the Outbox pattern.

The perceived hidden costs and poor developer experience associated with EDA, manifesting as increased microservices, databases, and complex local setups, are also, according to Comartin, symptoms of a deeper misconception. He asserts that EDA does not mandate microservices or independent physical deployments; an event-driven approach can be effectively implemented within a monolith, using logical boundaries for different domains (e.g., customers, orders, billing) without requiring separate infrastructure for each. The core value of EDA lies in temporal decoupling, not physical distribution. Comartin concludes by emphasizing a crucial architectural principle: first define logical boundaries, then choose communication methods (synchronous/asynchronous), and only then determine deployment strategies. Reversing this order, driven by premature scaling concerns, is identified as the root cause of much of the pain attributed to EDA.