Chapter 15 — Event-Driven Architecture Style

Core ideas

• Distributed, asynchronous, message-driven. Two primary topologies:
  • Broker topology — no central mediator; events chain through channels; highly decoupled and scalable, but no central control of the workflow (hard to restart/error-handle).
  • Mediator topology — an event mediator orchestrates a known workflow; better control/error handling/recoverability, at the cost of coupling and a potential bottleneck.
• Initiating event vs. processing/derived events; event processors; the difference between an event (something happened, broadcast) and a message/command (directed request).
• Async concerns: error handling (the workflow event pattern with a dead-letter/error queue and a reprocessing “event reprocessor”), data loss prevention (persistent queues, client/broker acknowledgment, “synchronous send,” last-participant support), broadcast, request-reply (pseudo-synchronous over async), and preventing data loss during processing.
• Hybrids: event-driven can be layered onto other styles (e.g., event-driven microservices).

Trade-offs / when to use

Best-in-class performance, scalability, elasticity, fault tolerance, evolvability. Costs: testability, debugging, and reasoning are hard; eventual consistency; complex error handling. Choose async when responsiveness and throughput trump simplicity and immediate consistency.