Event-Driven vs. Request-Driven Architecture
The problem
A whole system's communication style can be built around direct, synchronous calls (ask and immediately wait for an answer) or around asynchronous events (announce that something happened, let interested parties react whenever they're ready) — choosing at the architecture level, not just per-integration, has consequences for coupling, resilience, and how the system evolves.
Why now
Message queues and event-driven architecture already covered the mechanism at the level of one producer and its consumers; this topic is choosing that style as a system-wide default versus request-driven calls, and monolith vs. microservices already established that this choice interacts directly with how tightly services depend on each other.
Mental model
Request-driven architecture asks a direct question and waits for an answer — simple to reason about, but couples the caller to the callee's availability in real time. Event-driven architecture publishes a fact and moves on — decoupled in time and failure the way message-queues-and-event-driven-architecture already established, but harder to reason about because 'what happens next' is scattered across whichever consumers choose to react, not visible in one place.
Requires
- Message Queues & Event-Driven ArchitectureDistributed Systems
This topic is choosing event-driven communication as an architecture-wide default; you need the concrete producer/consumer mechanism already covered before evaluating it as a system-level design choice rather than a single integration technique.
- Monolith vs. MicroservicesSoftware Architecture
The choice between event-driven and request-driven communication is largely moot in a monolith (function calls) and becomes a real, consequential decision only once a system is split into independently deployable services — you need that context already established.
Used in
- Choosing between REST/RPC calls and an event bus (Kafka) as a system's primary communication style
- Explaining why event-driven systems are harder to trace ('what triggered this?') despite being more resilient
- Hybrid architectures using request-driven calls for reads and event-driven flows for writes/side effects
- Onboarding new engineers to an event-driven system, where the overall flow isn't visible in any single file
Projects
- Design the same feature (e.g. 'user signs up, send welcome email, provision account') twice — once request-driven (a signup service calling email and provisioning services directly), once event-driven (publishing a 'user signed up' event) — and compare coupling and failure behavior
- Trace a bug in a hypothetical event-driven system where the root cause is three services away from the visible symptom, and explain why this is harder to debug than an equivalent request-driven chain
Examples
- A request-driven signup flow fails the whole signup if the email service is down; an event-driven one completes signup regardless and the email is sent whenever that service recovers
- Debugging 'why did this user get charged twice' in an event-driven system may require tracing through a chain of independently-reacting consumers instead of reading one linear call stack
Resources
Mastery checklist
- I can design the same feature both request-driven and event-driven, and compare the tradeoffs
- I can explain why event-driven systems are more resilient to a single downstream failure
- I can explain why event-driven systems are harder to trace and debug
- I can identify when a hybrid approach (request-driven reads, event-driven side effects) is appropriate