distributed-aggregation-and-barrierslisted

# Distributed Aggregation And Barriers ## Purpose Get one correct, reproducible answer out of many workers, and pay as little synchronisation for it as the answer requires. Two decisions carry the whole topic: what the combining function is allowed to be, and where — if anywhere — every worker must wait for every other. The failure this prevents is the aggregate that disagrees with itself. Same input, same code, a different partition order, and the total moves in the fifth decimal place; finance opens a reconciliation ticket nobody can reproduce, because the cause is that floating-point addition is not associative and the shuffle is not deterministic. The second failure is the barrier nobody named: a job of ten thousand tasks whose wall-clock time is set entirely by two of them, where adding workers changes nothing at all. ## Workflow 1. **Write the aggregate contract.** Define identity, accumulator, merge, finish, input domain, overflow/error policy and whether encounter order is semantically relevant. Associativity is required for arbitrary grouping; commutativity is required only when partials may be reordered. Neither prevents double-counting a repeated attempt. 2. **Rewrite aggregates that lack a mergeable sufficient state.** Average becomes a `(sum, count)` pair; variance becomes `(n, mean, M2)`; a percentile becomes a mergeable histogram; a ratio carries numerator and denominator separately. 3. **Choose a summary per metric and state its error.** Exact