A price lookup is sent to three redundant sources and the first answer wins; what must happen to the two losers?

## What the rule actually does First-to-respond selection takes several candidate sources that are expected to produce the *same* answer and turns them into one output. It subscribes to all of them at the same moment, watches for the first signal, and then **commits**: the winner becomes the output, and every other subscription is cancelled. It is a selection rule, not a combining rule — the other candidates' values are not merged, buffered or reserved. The commitment is the part candidates misjudge in interviews. Once the winner is chosen, the losers are gone. If the winner produces one value and then hangs, or fails on its second value, the selection cannot fall back: there is nothing left to fall back to. Redundancy bought you a faster first answer, not a durable one. ## The three costs 1. **Work multiplies by the number of candidates.** Latency becomes the minimum of the candidates' latencies; load becomes the sum. With three sources you have traded three times the downstream load for the best of three response times, and every one of those calls occupies a connection and a worker for as long as it runs. 2. **Cancellation is a request, not a guarantee.** A cancelled subscription tells the source to stop; whether it stops depends on the source honouring it. Work already dispatched may run to completion, and anything it does that is visible outside the pipeline still happens. Selection is therefore safe over repeatable, side-effect-free reads and dangerous over anything that writes, charges, sends or reserves. 3. **A failure is a response.** The fastest candidate is often the one that fails immediately — a closed connection, a rejected request, a missing configuration. Formulations differ on whether the winner is decided by the **first signal of any kind**, including a failure, or only by the **first value**; the difference decides whether one instantly-broken candidate can poison a selection that had two healthy alternatives. Know which rule your pipeline uses before you rely on it. ## What "winning" can mean | the winner is decided by | consequence when one candidate fails instantly | |---|---| | the first signal of any kind | the failing candidate wins and the output fails, despite two healthy candidates | | the first value only | the failure is ignored, and the first candidate to actually produce data wins | | the first value, failures collected | the output fails only when every candidate has failed | ## Operating it - **The losers' outcomes disappear.** Two thirds of the work you dispatched produces no observable result at all, so error rates measured at the output understate what your downstream sources are doing. Record each candidate's outcome separately if you care whether one of them is quietly broken. - **A candidate that wins by failing fast makes the system look fast and broken at once.** Response-time metrics improve while the error rate climbs, which is a confusing pair of signals during an incident. - **Dispatching the second candidate after a short delay** keeps the usual case at one call while still capping the tail: nothing is sent to the alternatives unless the first has not answered within a chosen interval. The cost multiplier then applies only to slow requests rather than to all of them. - **Idempotence is the precondition.** Every candidate must be safe to invoke even when its result will be thrown away, because by design most of them will be. ## Where it fits and where it does not Use it where several sources are genuinely interchangeable and reading is cheap and repeatable: redundant read replicas of the same data, a local cache raced against the authoritative source, several mirrors of the same static content. Avoid it where the candidates are not equivalent (their answers differ, so which one wins changes the result), where a call costs real money per invocation, and where a candidate performs any effect that cannot be safely repeated or abandoned halfway. And separate it from the rules next to it. It is not lockstep pairing, which waits for every source; it is not latest-value combination, which keeps every source alive and re-emits on each arrival; it is not sequential appending, which runs candidates one after another and would give you a fallback but not a faster answer. Selection is the only one of the four that deliberately throws work away.