In a fulfilment pipeline, picking sends packing an asynchronous message instead of calling it — what does picking wait for?
answer
- the send ends at the boundary
- no thread, no frame, no result
- acceptance is not processing
- faults do not unwind across it
- answers come back as messages
basics
~10 sOnly for the message to be accepted for delivery, not for packing to run. Picking holds no thread and no result, and hears about the outcome only if a later message tells it.
solid answer
~40 sThe send finishes at the boundary. Picking builds a self-contained message, hands it toward packing's address and returns immediately — it keeps no thread, no call frame and no pending result, and it has no evidence that packing has started, only that the message was accepted. Because no call frame connects the two, a fault inside packing never unwinds into picking; picking's error handling covers sending, not handling. If picking needs an answer it arrives as another message, which means picking needs a reply address, a correlation value such as the order identifier, and somewhere to keep the in-flight order until the answer comes or is given up on. Latency per order does not improve — picking simply stops spending it.
code
pseudocode · 11 lines// direct call: picking holds the outcome and the failure
function pick(order)
items = reserve(order)
label = packing.pack(items) // picking waits right here
return label
// message-driven: picking hands the work on and moves along
function pick(order)
items = reserve(order)
send(to: packingAddress, PackOrder(order.id, items))
return // no label, nothing waited forgo deeper
Recall that the send returns once the message is accepted for delivery, and that the sender gets no result and no error from the recipient's work. Any answer arrives later, as a separate message.
Explain the two decouplings — in time and in fate — and what replaces the call frame: a reply address, a correlation value, and explicit state for work still in flight.
Show that you plan for the quiet failure this creates. Absent replies, not raised errors, are the signal, so the sender needs its own notion of too long and the boundary needs measurement.
Frame the trade honestly: per-order latency usually rises while the system stops propagating one component's slowness everywhere. Decide which boundaries are worth that bookkeeping and which should stay direct calls.
## Two components, two ways to hand over work In a fulfilment pipeline, picking gathers the items for an order and packing puts them in a box. There are two ways picking can hand that work over, and the difference is not stylistic: it decides what picking holds while packing works, and what picking finds out when packing fails. A **direct call** puts both components on one thread of execution. Picking's call frame stays on the stack holding the order, the items and the expectation of a return value. Packing's duration becomes part of picking's duration. Packing's failure unwinds into picking's frame. An **asynchronous message send** ends at the boundary. Picking builds a message — a self-contained description of the work to be done — hands it toward packing's address, and returns. The send completes when the message is accepted for delivery, not when packing has done anything with it. ## What picking waits for Only the handoff. Concretely, once the send returns: - picking holds **no thread** parked on packing; - picking holds **no result** — there is no label, no confirmation, nothing to inspect; - picking has **no evidence** that packing is even running, only that the message was accepted toward its address; - picking will **not** receive packing's failure as an exception, because no call frame connects them. That last point surprises people most. On a message boundary the sender's error handling covers *sending*, not *handling*. A fault inside packing belongs to packing, which must record it, retry it, or escalate it to whatever supervises packing. ## The two kinds of decoupling this buys 1. **Decoupling in time.** Picking's rate is no longer tied to packing's. If packing is momentarily slow, picking keeps accepting orders, and the difference in rates accumulates at the boundary instead of travelling backwards as latency. 2. **Decoupling in fate.** A stalled or crashed packing cannot hold picking's resources hostage, because picking lent it nothing — no thread, no frame, no lock. | | Direct call | Asynchronous message | |---|---|---| | what the sender holds | a frame, a thread, a pending result | nothing once the send returns | | when the sender learns of failure | immediately, as a raised error | only if a later message says so | | sender's latency | includes the recipient's work | excludes the recipient's work | | what the sender must know | the recipient's interface | an address and the messages it accepts | ## Getting an answer back Asynchronous does not mean answerless. It means the answer is another message. Where picking genuinely needs one, three things must exist: an **address** for the reply to be sent to, a **correlation value** such as the order identifier so the reply can be matched to the request that caused it, and **somewhere to keep the in-flight state** until the reply arrives or picking decides it never will. That third item is the real cost. A call stack tracked in-flight work for free: the frame *was* the record that an order was half-done. Once the frame is gone, the sender owns that bookkeeping explicitly. Fire-and-forget — where picking genuinely does not care what happens next — is the cheap case, not the only case. ## What this costs - **Per-order latency does not improve.** The work still takes as long, and usually a little longer, because a handoff and a queue were added. What improves is that the sender is not the one spending that time. - **Failure becomes quiet.** Nothing is raised and nothing stops. A recipient that is not processing looks exactly like one that is merely busy, until somebody measures. - **Messages must be self-contained.** A message carrying a reference into the sender's live state is a direct call in disguise; the recipient may be in no position to follow that reference. - **Ordering is narrower than people assume.** Two messages produced by two different senders are not put in order by the boundary just because one was created first. ## Two ways to fake it Moving the same direct call onto a background worker makes the *caller* non-blocking without making the *boundary* message-driven: the caller still names the component, still depends on its availability to get a result, and still receives its failure. Returning a placeholder that the caller resolves later has the same shape — it changes what the wait looks like, not the direction of the dependency. The boundary becomes message-driven when what crosses it is a self-contained message addressed to a recipient, and the sender's next action does not depend on what that recipient does with it.
- If picking does not wait, how does it ever learn that packing succeeded?Through a later message. Packing sends a result to a reply address, carrying the order identifier so picking can match it to the request. Picking must keep enough in-flight state to do that matching, or hand ownership of the outcome to some other component entirely.
- Does an asynchronous send mean picking can never be slowed by packing?No. Decoupling in time is real but not unlimited. If the boundary applies flow control, a full intake eventually makes the send itself wait or be refused, and picking feels it. What is removed is the per-order coupling, not every possible form of pressure.
- Is running the existing call on a background worker the same thing?No. The caller stops blocking, but it still names the component, still needs it available to get a result, and still receives its failure. The dependency and its direction are unchanged; only the shape of the wait moved.
saying these in an interview costs you the question
- Asynchronous means each order is processed faster
- The sender catches the recipient's exception where it sent the message
- A completed send means the recipient accepted and started the work
- A sender needing a reply keeps no state to match it against
- Putting the same direct call on another thread makes the boundary message-driven