Event-Driven vs Request-Driven

Request-driven and event-driven are two fundamentally different communication styles for making distributed systems talk to each other, and the difference isn't really about the transport (HTTP vs a message broker) — it's about **what each side commits to and when**. ## Request-driven: the caller waits In a **request-driven** (synchronous request/response) interaction, service A calls service B and, conceptually, blocks until B replies. Even when the call is technically non-blocking (a Promise, a Kotlin coroutine, a callback), A's business logic cannot proceed past that call site until it has B's answer — there's a causal, in-the-moment dependency. This means: | # | What follows from it | |---|---| | 1 | Both A and B must be reachable and healthy at the same instant. | | 2 | A's tail latency includes B's tail latency plus network round trip. | | 3 | If B is down, A's request fails immediately, and A must decide right there how to handle it (retry, fallback, error to its own caller). | The mental model is a synchronous function call or a phone call — you dial, you wait, you get an answer or a busy signal. ## Event-driven: publish and walk away In an **event-driven** interaction, service A does something in its own transaction (e.g., "order placed"), then publishes a fact about that — an **event** — to a broker or log (Kafka, RabbitMQ, SNS/SQS, an outbox table read by a relay). A does not wait for anyone to consume that event; from A's point of view, the interaction is over once the event is durably stored. Zero or more consumers (B, C, D…) subscribe to that event type and process it whenever they poll or receive it — a second later, or an hour later if they were down. The mental model is a postal letter or a bulletin-board announcement: you post it and walk away; whoever reads it, reads it on their own schedule. ## What each style buys The distinction exists because the core value event-driven design buys is **temporal decoupling** — producer and consumer no longer need to be simultaneously available. This unlocks two related benefits: - **Autonomy** — each service can deploy, scale, and fail independently without a synchronous chain reaction. - **Resilience** — a consumer outage doesn't cascade back to the producer; events simply queue up and get processed once the consumer recovers. Request-driven communication, by contrast, buys you an immediate, in-band answer — you know synchronously whether the operation succeeded, and can return that result straight up your own call stack to whoever is waiting on you. ## The trade-offs The trade-offs cut both ways. Choosing events costs you: - **Strong, immediate consistency.** Because processing is deferred, the rest of the system is momentarily out of sync with the fact that just occurred — this is "eventual consistency," and callers who need a same-millisecond guarantee can't get it from an event alone. - **Straightforward reasoning.** A request-driven call chain is a stack you can read top to bottom; an event-driven flow is a graph of independent reactions whose overall order and effect you must reconstruct mentally or with tracing tooling, because there's no single thread of control. Choosing requests costs you availability and autonomy: a synchronous chain is only as available as its least-available link, and it tightly couples deploy/scaling of both sides. ## The classic failure of each style In production, each style has its own classic failure. - **Request-driven — cascading latency/failure.** A slow downstream service without a timeout or circuit breaker drags every upstream caller down with it (thread-pool exhaustion, connection-pool starvation). - **Event-driven — silent staleness, or duplicate/out-of-order processing.** A consumer falls behind (consumer lag) and nobody notices until a customer complains their order status is "stuck," or a message is redelivered after a crash and a non-idempotent handler double-charges someone. ## A worked example: checkout Consider checkout at an e-commerce site as a worked example. Payment authorization is almost always request-driven — the customer is sitting there waiting for "your card was charged" or "declined," so it has to be synchronous and give an immediate answer. But once payment succeeds, "notify the warehouse to prepare the shipment," "send a confirmation email," and "update the recommendation engine" are classic event-driven work: an `OrderPlaced` event is published once, and inventory, email, and analytics services each react independently, none of them blocking the checkout response, and none of them able to bring checkout down if they're temporarily unavailable.