23.5 What is event-driven architecture?

On the paper round: The press doesn't call each reader to tell them the news. It prints the paper. Whoever subscribes reads it and does what they like: the stockbroker trades, the student cuts out the crossword. The press never needs to know.

In the system: In event-driven architecture, services announce facts ("order placed", "payment captured", "book released") instead of calling each other with instructions:

Figure: with events, a new feature is a new subscriber; the publisher doesn't change.

What you gain:

• Loose coupling. Checkout doesn't know about loyalty points. Adding a "recommend similar books" service means subscribing to order_placed, not editing checkout.
• Resilience. If the loyalty service is down, orders still go through; it catches up from the topic later.
• A history. With a retained log, events are a record you can replay to rebuild a view or feed a new service (Chapter 22).

What it costs:

• Harder to follow. "What happens when an order is placed?" is now spread across many services. You need tracing with a correlation ID (Chapter 30) and a catalogue of who publishes and subscribes to what.
• Eventual consistency. Points appear a moment after the order (Chapter 16).
• Coordination across steps needs care: a multi-step business process driven purely by events is choreography; with a coordinator it's orchestration (Chapter 17's sagas).

Two styles of event payload worth naming:

• Notification events: "order 881 placed"; consumers call back for details.
• Event-carried state: "order 881 placed, total ₹1,248, items [...]"; consumers don't need to call back, at the cost of bigger events.

Memory code: "Announce what happened; let whoever cares react."

---