Event-Driven Architecture

Decoupling Makes Systems Resilient

Event-Driven Architecture (EDA) is a paradigm where the flow of the application is controlled by events, for example "customer has ordered" or "inventory low." Instead of systems waiting for each other (synchronous), they react to these events with a time delay (asynchronous).

This leads to an extreme decoupling of systems: The webshop does not need to know how the shipping system works. It only publishes the event "order completed" and leaves the rest to the infrastructure. How such event-driven data flows combine into controlled, automated processes across system boundaries is covered by Workflow Automation and Data Flows.

sequenceDiagram
    participant Shop as Webshop
    participant Broker as Message broker
    participant Logistics
    participant Billing
    participant CRM as CRM / marketing
    Shop->>Broker: Publish Ordered event
    Broker-->>Logistics: Prepare shipment
    Broker-->>Billing: Create invoice
    Broker-->>CRM: Prepare follow-up
    Logistics-->>Broker: Shipping label created
    Billing-->>Broker: PDF invoice created
    CRM-->>Broker: Follow-up email scheduled

Anti-Patterns: The House of Cards Syndrome

In synchronous architectures (request-response), the failure of a single small sub-system often leads to the standstill of the entire process. If the invoicing system is slow, the checkout in the webshop aborts because it waits for the response. This limits scalability and makes the system vulnerable to load peaks.

The Reactive Organisation

1. Message Broker / Event Bus: Use of specialised middleware (e.g. RabbitMQ, Kafka, or NATS) that securely stores and distributes events.
2. Pub/Sub Pattern: Senders (publishers) and receivers (subscribers) do not know each other. This allows adding new systems at any time without changing existing code.
3. Eventual Consistency: Acceptance that data does not have to be exactly the same everywhere at every point in time, as long as it "eventually" becomes consistent.
4. Resilience through Buffering: If a receiver system is offline, the events are buffered in the broker and processed later as soon as the system is back online.
5. Audit Log as an Option: EDA does not automatically mean durable recording of every event. If Event Sourcing is deliberately implemented (a separate pattern where all state changes are stored as events), the events can become the system of record and thus a complete history of business transactions.

The Advantage: High Scalability

Events can be processed in parallel on a massive scale. Load peaks in the frontend are smoothed by the event bus, so that the backend systems can continue working stably at their own pace.

FAQ

Is EDA not much harder to debug than synchronous calls?

It requires different tools (Distributed Tracing). But the ability to replay events makes it even easier in complex scenarios to find and fix errors.

What does Eventual Consistency mean for our business?

The delay is system-specific and depends on topology, failure modes, queues, conflict resolution, backpressure, retry policy, and the business workflow. Eventual consistency guarantees no fixed millisecond bound; the expected delay belongs defined and measured as an SLO. In many cases the customer receives the confirmation email shortly after clicking, and the purchase process does not abort just because the mail server is currently busy.

References

• Bellemare, Adam Building Event-Driven Microservices. EDA in practice. (2020). www.oreilly.com/library/view/building-event-driven-microservices/9781492057888/
• Kleppmann, Martin Designing Data-Intensive Applications. Foundations of modern data architectures. (2017). dataintensive.net
• Jonas, Roland et al. Reactive Manifesto. Principles for elastic and resilient systems. (2014). www.reactivemanifesto.org