Event-Driven vs Request-Driven Architecture Trade-offs

Intermediate·2 min read·

Fast recall

Quick revision

Core answer

Event-driven architecture decouples producers from consumers via an event broker, enabling asynchronous processing, better scalability, and fault tolerance—but introduces eventual consistency, harder debugging, and infrastructure complexity. Request-driven (REST/gRPC) is simpler, provides immediate consistency and error feedback, but couples services directly and limits scalability under load spikes.

Interview Answer2 min

Event-driven and request-driven architectures represent fundamentally different approaches to service coupling.

In synchronous REST or gRPC, the caller blocks until the downstream responds — both services must be healthy at the same moment.
When the inventory service starts responding in 5 seconds instead of 200ms, the order service's threads pile up, and you get a cascading failure that takes down unrelated features.

Why event-driven breaks temporal coupling:

The order service publishes an event to a broker and returns immediately — the inventory service processes it whenever it is ready, even minutes later after recovering from an outage
The producer is completely unaware of who consumes the event, so adding new consumers — analytics, fraud scoring, notifications — requires zero producer changes and no additional publish latency
Fan-out at scale: adding a fourth synchronous downstream call multiplies the failure surface and latency; adding a fourth Kafka consumer group costs nothing on the producer side

The consistency trade-off:

Synchronous calls give you an immediate answer — the payment either worked or it didn't, and you can tell the user in the same HTTP response
With events, you get eventual consistency — the user placed an order but downstream services haven't finished processing; you need patterns like optimistic UI, polling endpoints, or WebSocket notifications to bridge that gap
The dual-write problem: saving to the database and then publishing to Kafka creates a crash window where the event is lost; the Outbox pattern writes both in one database transaction

How production systems use both:

The user-facing request path is synchronous — payment authorization, search results, validation — because users need immediate answers
Everything behind that boundary is event-driven: emails, inventory updates, analytics, and fraud scoring process independently

I recommend sync for user-facing feedback that requires an immediate answer, async for everything else, and always the Outbox pattern at the boundary between transactional writes and event publishing.

Interview-ready guide

Interview answer

Event-driven and request-driven architectures represent fundamentally different approaches to service coupling.

In synchronous REST or gRPC, the caller blocks until the downstream responds — both services must be healthy at the same moment.
When the inventory service starts responding in 5 seconds instead of 200ms, the order service's threads pile up, and you get a cascading failure that takes down unrelated features.

Why event-driven breaks temporal coupling:

The order service publishes an event to a broker and returns immediately — the inventory service processes it whenever it is ready, even minutes later after recovering from an outage
The producer is completely unaware of who consumes the event, so adding new consumers — analytics, fraud scoring, notifications — requires zero producer changes and no additional publish latency
Fan-out at scale: adding a fourth synchronous downstream call multiplies the failure surface and latency; adding a fourth Kafka consumer group costs nothing on the producer side

The consistency trade-off:

Synchronous calls give you an immediate answer — the payment either worked or it didn't, and you can tell the user in the same HTTP response
With events, you get eventual consistency — the user placed an order but downstream services haven't finished processing; you need patterns like optimistic UI, polling endpoints, or WebSocket notifications to bridge that gap
The dual-write problem: saving to the database and then publishing to Kafka creates a crash window where the event is lost; the Outbox pattern writes both in one database transaction

How production systems use both:

The user-facing request path is synchronous — payment authorization, search results, validation — because users need immediate answers
Everything behind that boundary is event-driven: emails, inventory updates, analytics, and fraud scoring process independently

03 · Deep dive