The Problem with Direct Calls
In a distributed system, services need to communicate. The most intuitive approach is synchronous request/response: Service A calls Service B's API, waits for a response, and continues. This works well for simple cases but creates a hidden dependency: if Service B is slow or unavailable, Service A is blocked and eventually fails too. In a chain of five services, one slow service can cascade into a full system outage.
Event-Driven Architecture (EDA) solves this by changing the communication model entirely.
How EDA Works
Instead of calling another service directly, a service publishes an Event — a record of something that happened — to a message broker such as Apache Kafka or RabbitMQ. The publishing service does not know or care who is listening. It simply states a fact and moves on.
Other services subscribe to the events they care about. When an event arrives, they process it independently, at their own pace.
[Order Service]
│
│ publishes: OrderPlaced { orderId: 123, userId: 456, items: [...] }
▼
[Message Broker (e.g., Kafka)]
│
├──► [Inventory Service] → reserves stock
├──► [Email Service] → sends confirmation email
└──► [Analytics Service] → records the sale
The Order Service responds to the customer immediately after publishing the event. It does not wait for inventory to be reserved or the email to be sent.
The Trade-off
Pros: Services are temporally decoupled — if the Email Service is down for an hour, it processes the backlog of events when it comes back up. No events are lost. The Order Service is unaffected. Adding a new downstream step (like a fraud detection service) requires zero changes to the Order Service — just subscribe a new service to the existing event.
Cons: The system becomes eventually consistent. The customer's confirmation email might arrive 200ms after they see the "Order Confirmed" page, or 30 seconds later if the Email Service is under load. You lose the ability to guarantee that all steps completed before responding to the user. Debugging requires correlating events across multiple services and time windows, which demands good tooling (distributed tracing, structured logging with correlation IDs).