A team is building a form submission flow where the page must immediately show a computed result (e.g., a loan eligibility score) before rendering. Why would implementing this specific interaction as an event-driven, publish-and-react flow be a poor fit compared to a direct synchronous call?
answer
- one requester, one answer, needed now = sync
- events have no built-in response channel
- forcing request/response over events reinvents RPC badly
- fan-out value only shows up post-response
- silent timeout risk without hand-built correlation cleanup
basics
~20 sThe user is waiting right there for an answer. Event-driven flows don't promise a fast, in-order response, so making them wait for a broadcast-and-hope-someone-answers pattern is the wrong tool — a simple direct call that returns the answer is simpler and faster here.
solid answer
~40 sEvent-driven style is built around fire-and-forget, temporally decoupled communication with no built-in request/response contract — the producer doesn't get an answer back through the same channel it published on. A UI that needs a synchronous, immediate result needs a call/response contract with bounded latency and a way to correlate 'my request' to 'its answer,' which is what a direct synchronous call gives naturally. Forcing this into events means building a request-event plus a matching response-event plus a correlation ID plus a client-side wait/poll/callback mechanism — reinventing request/response on top of infrastructure designed to avoid it, adding latency, complexity, and new failure modes (what if the response event never comes?) for no benefit, since there's exactly one interested party waiting for exactly one answer.
go deeper
Should recognize that a user waiting for an immediate answer needs a direct call, not a broadcast-and-hope pattern.
Should explain that events lack a built-in response channel and that forcing request/response over them reinvents RPC.
Should identify the specific new failure modes (silent timeout, hand-built correlation cleanup) introduced by forcing this pattern.
Should articulate the decision heuristic (single requester needing an immediate answer vs. genuine multi-consumer fan-out) and show where the same feature can legitimately mix both styles.
## Events have no return channel Event-driven style's core contract is one-way and un-addressed: publish an event, and zero or more consumers may react at their own pace — there is no return channel built into 'publish.' Getting a response back requires bolting a second, separate mechanism on top: - typically a **correlation ID** embedded in the outgoing event, - a dedicated **response event type** published by the consumer once it's done, - and something on the producer side (a temporary subscription, a polling loop, or a push mechanism) that waits for and matches the correlation ID back to the original caller's context. Contrast a synchronous call: the caller opens a connection, sends a request, and the same call stack or connection carries the response back, with the client library handling correlation, timeout, and error propagation for free. ## Why this interaction is the wrong shape for events The interaction described — user submits, page needs the number before it can render — has exactly the shape synchronous request/response was built for: - a single requester, - a single well-known responder, - an answer needed before the caller can usefully proceed, - and normal human-perceptible latency bounds. None of the properties that motivate event-driven design apply here: - there's no need for multiple independent parties to react to 'form submitted' (only one thing needs to happen: compute and return the score), - no benefit from decoupling the caller from the callee's deployment lifecycle (the caller needs the callee, full stop, to answer), - and no benefit from surviving the callee's downtime (if the scoring service is down, the user needs to know now, not have it work out eventually). ## What forcing it costs Adding events for a one-off, immediate-response interaction: 1. adds **latency** — typically an extra hop or two through a channel plus consumer wake time versus a direct call, 2. adds **moving parts** (request-event schema, response-event schema, correlation-tracking storage, timeout/cleanup logic for correlations that never get a response), 3. and adds **new failure modes** that don't exist in synchronous calls. What does the UI do if the response event never arrives because the consumer crashed mid-processing? A synchronous call fails loud and fast with a timeout or a 5xx error; an artificially event-driven request/response can fail silently, leaving the UI waiting indefinitely unless someone explicitly builds a timeout into the correlation-tracking layer, duplicating exactly the timeout handling a synchronous HTTP client gives for free. ## The practical heuristic The practical heuristic is: does exactly one party need an answer, right now, before it can proceed? If yes, a direct call is the right tool, and event-driven publish/react should be reserved for the parts of the same feature where fan-out or decoupling genuinely helps. Once the loan score is computed and shown, publishing a `LoanScoreComputed` event so an analytics consumer, a marketing-offer consumer, and an audit-log consumer can independently react is exactly the fan-out case events are good at, because none of those three need to block the user's page render or give the caller an answer back. Teams that reach for events by default for every interaction, including simple synchronous ones, typically end up building a bespoke, worse version of RPC on top of a messaging system — more latency, more code, and weaker tooling than just calling an endpoint directly. ## The anti-pattern and the good split - **A common real anti-pattern** is teams building a 'please wait' UI backed by publishing a request event and long-polling or subscribing for a matching response event for something like a synchronous price quote or eligibility check — in practice this is strictly worse than the equivalent direct call for the same interaction, because the correlation and timeout machinery has to be hand-built, defeating the entire premise of decoupling that made events attractive elsewhere in the system. - **Conversely, a well-known good split** is: the checkout button click that needs an immediate 'order accepted, here's your confirmation number' response is a synchronous call, while everything after that response — inventory reservation confirmation, shipping label generation, marketing email, loyalty points — is where event-driven fan-out earns its keep, because none of those need to complete before the user sees confirmation.
- If a team insists on using events even for this synchronous-shaped interaction, what specific piece of infrastructure will they end up rebuilding?They'll end up rebuilding request/response correlation and timeout handling — a way to match an incoming response event back to the waiting caller, plus logic to give up and surface an error if no response event arrives within a bound — which a synchronous RPC/HTTP client already provides out of the box.
- Is there a middle ground between pure synchronous calls and pure fire-and-forget events for this kind of interaction?Yes — request/reply patterns over a message channel (a temporary reply destination plus correlation ID) exist and are sometimes used when you want messaging infrastructure's other benefits while still getting a response, but they're strictly more complex than a direct call and are usually only worth it when the same infrastructure is already in place for other, genuinely asynchronous parts of the system.
- Once the loan score is computed and returned synchronously, why might publishing an event at that point still be worthwhile?Because at that point the remaining work — analytics, marketing offers, audit logging — genuinely has multiple independent, unrelated consumers that don't need to block the user's response, which is exactly the fan-out case event-driven design is good at; the synchronous and event-driven parts of the same feature aren't mutually exclusive.
It's like sending a certified letter and waiting by the mailbox for a reply when you could just make a phone call — technically you'll get an answer eventually, but you've built extra machinery to simulate a conversation that a direct call already gives you for free.
saying these in an interview costs you the question
- Proposes events as the default for every interaction regardless of shape
- Doesn't recognize that events lack a built-in response channel
- Can't name the correlation-ID/timeout machinery that would need to be hand-built
- Thinks decoupling is free and has no latency/complexity cost
- Confuses this with a delivery-guarantee or broker-technology question