A transfer service routes every failure through its result type, including programming bugs. What does that cost its callers?

## Two questions that decide where a failure goes Before a failure is given a shape in the return type, two questions settle whether it belongs there at all. 1. **Is this outcome part of what the operation promises, or a sign that its own assumptions are broken?** "The destination account is not in the directory" is one of the transfer's honest endings. "The fee table was indexed past its end" is not an ending of the transfer; it is evidence that the implementation is wrong. 2. **Does the immediate caller have a decision to make about it?** A caller told the currency is unsupported can offer another currency. A caller told that memory ran out has nothing to choose; the only sensible thing is for the request to stop and for somebody to be told. When both answers point the same way the classification is easy. The interesting cases are the ones where a team answers the first question honestly and the second one not at all, and ends up threading a failure through five layers that each just pass it along. ## What belongs in the channel - **Rejections the domain anticipates**: a non-positive amount, an unsettled currency, an unknown destination, a balance too small. - **Outcomes a caller can route on**: anything where the caller's behaviour genuinely differs between two failure shapes. - **Failures a boundary must render**: the things a response has to explain to whoever made the request. ## What does not - **Broken assumptions inside the implementation.** A violated invariant is not an outcome of the operation; converting it into one launders a bug into ordinary business. - **Faults nobody anticipated.** An unreachable ledger or an exhausted resource is real and important, but the immediate caller has no decision to take on it; it belongs to the boundary that retries, alerts or fails the request. - **Conditions whose only handler is "give up".** If every caller's branch is identical and does nothing, the branch is ceremony and the channel bought nothing. | kind of failure | example in a transfer | where it belongs | what the caller does | |---|---|---|---| | anticipated domain rejection | destination account unknown | the described-failure channel | chooses, reports, or re-routes | | broken internal assumption | fee table indexed past its end | stops the operation loudly | nothing; it is a defect to fix | | environmental fault | ledger unreachable | a boundary that retries or alerts | usually nothing at its own level | ## What sprawl actually costs 1. **Every signature in between.** The failure type appears in each function that passes it, so a shape added deep down edits the vocabulary of layers that never produce it. 2. **Every match.** Callers enumerate shapes they can do nothing with, and the three shapes that matter sit among a dozen that do not. 3. **The catch-all branch.** Faced with shapes it cannot act on, a caller writes one branch for everything else — and that branch now silently absorbs defects too. The loudest signal a defect could give, stopping the operation, has been traded for a value that flows on. 4. **The description dilutes.** A failure type that means both "the user asked for something we do not do" and "we are broken" cannot be rendered, logged or measured as either one. 5. **Review attention.** When every signature mentions failure, the ones where it is interesting stop standing out. ## Keeping the line honest The repair is not to move everything back out again; it is to size the channel per boundary. Each layer declares the small set of failures its callers can decide about, and re-describes anything arriving from below into that vocabulary or lets it stop the operation. A defect kept out of the channel is not ignored — it reaches the place that logs, alerts and fails the request, with its stack and its context intact. That is the value of a failure that is allowed to be loud. A useful test on an existing codebase: take one failure shape and ask which caller branches differently because of it. If the honest answer is "none", it is occupying a channel that costs every layer in between. ## What interviewers listen for - That you can name a failure the immediate caller has **no** decision about, and say what you do with it instead. - That you treat the cost as structural — signatures, matches, the catch-all — rather than aesthetic. - That you do not argue for a codebase with no loud failures at all; a defect that stops the operation is a feature.