Event-driven vs RPC

RPC says "do this and tell me the result." Events say "this happened, fan out." Architectures get complex when you conflate them.

How It Works

RPC (remote procedure call) is 1

synchronous request-response — caller knows exactly who they're calling (POST /users/create) and expects a response. Event-driven is 1 asynchronous broadcast — producer emits user.created and doesn't know or care who's listening. RPC is simpler to reason about and debug; failures are localized to the caller. Event-driven is more loosely coupled — new consumers subscribe without touching the producer — but introduces discovery problems (who's listening?) and debugging challenges (what happened to my event?). Rule: use RPC when the answer matters right now and the calling service owns the outcome; use events when multiple teams want to react independently to a state change. In interviews, every queue (see Queues) or topic you draw should have exactly one producer role — if two producers write to the same topic, that's probably an RPC in disguise.

Real-World Example

Uber migrated core trip state changes (trip-started, driver-arrived, payment-completed) from RPC to event-driven because multiple teams needed to react: rider app, driver app, fraud detection, analytics pipeline, loyalty program. Before, each new consumer required modifying the trip service to add another direct call. After, new consumers subscribe to the event stream independently. But RPC still rules on the critical path: when a rider requests a ride, the matching service calls driver service synchronously — the rider is waiting on the result, so fire-and-forget would break the product.