When one service calls another service directly, it has to know where that service lives, wait for a response, and handle the failure if the other service is slow or down.

That is fine for many cases. But it gets awkward when many services need to react to the same change.

Imagine an order is placed. Inventory needs to reserve stock. Payments may need to charge the customer. Email may need to send a receipt. Analytics may need to record the sale. If the order service calls all of them directly, it becomes responsible for knowing every other service and waiting on their work.

Event-driven architecture changes that shape. A service publishes an event saying something happened. Other services listen for that event and react in their own time.

The benefit is looser coupling. The producer does not need to know who is listening. New consumers can be added later without changing the producer.

The trade-off is that the system becomes harder to reason about. Events may be processed later, more than once, or in an unexpected order. Debugging also requires better tracing because work is no longer happening in one direct call chain.

This chapter explains event-driven architecture in practical terms: what events are, how they differ from commands and queries, how producers, brokers, and consumers work together, and how to handle payloads, delivery, ordering, schema changes, reliability, and replays.