Event-Driven vs Request-Driven

The choice between event-driven and request-driven architecture determines how services communicate, how tightly they are coupled, and how the system behaves under failure.

Fundamental Difference

In request-driven architecture, Service A calls Service B and waits for a response. The caller knows exactly who it is talking to and what response to expect. This is synchronous, direct, and simple.

In event-driven architecture, Service A publishes an event ("OrderPlaced") to a message broker. It does not know or care who consumes it. Service B, C, and D subscribe independently and react at their own pace. This is asynchronous, indirect, and decoupled.

The Coupling Trade-Off

Event-driven architecture dramatically reduces coupling. When you add a new feature (e.g., sending a welcome email after user signup), you add a new consumer — the user service does not change. In a request-driven system, the user service would need to call the email service directly.

This decoupling is powerful for large organizations where different teams own different services. See our event-driven architecture concept for deeper patterns.

The Consistency Trade-Off

The flip side is consistency. Request-driven systems can chain synchronous calls in a transaction. Event-driven systems are eventually consistent — the event is published, but consumers may process it seconds or minutes later. Handling out-of-order events, duplicates, and failures requires patterns like idempotent consumers and dead letter queues.

In Practice: Use Both

Most production systems use both patterns. Synchronous REST/gRPC for user-facing request-response flows. Asynchronous events for background workflows, notifications, and cross-service data propagation.

For interview preparation, see our system design interview guide and interview questions. Check pricing for full access.

The Bottom Line

Use request-driven for synchronous user-facing operations. Use event-driven for decoupled, scalable background workflows. The best architectures blend both.