# Above one tier, reduction

> This section covers what happens above one tier, where a flat surface becomes the accumulation and the shape that survives is a tree, as shown in [reduction].

Page: Architecture · Scale
Canonical: https://banes-lab.com/software-architecture/scale#above-one-tier-reduction

This section is stop 99 of 102 in the learning route. Previous: [02 - The ceiling moves by cost](https://banes-lab.com/software-architecture/scale/the-ceiling-moves-by-cost.md). Next: [04 - The author is probabilistic](https://banes-lab.com/software-architecture/scale/the-author-is-probabilistic.md). It builds on [01 - A concern is a component](https://banes-lab.com/software-architecture/scale/a-concern-is-a-component.md), [02 - The ceiling moves by cost](https://banes-lab.com/software-architecture/scale/the-ceiling-moves-by-cost.md).

This section covers what happens above one tier, where a flat surface becomes the accumulation and the shape that survives is a tree, as shown in [C1·a reduction](https://banes-lab.com/software-architecture/scale#above-one-tier-reduction-panel-a).

### Fused results up, scope down

Flat fan-in grows without bound, and the growth is read as a discipline problem when it is the structure doing exactly what it was built to do. An orchestrator forwards its workers' raw records upward, the composer reads everything every worker wrote, and the surface that was supposed to bound reading has become the unbounded thing it replaced. Fan-in without reduction passes every record to every reader, so the volume a party has to read grows with the population, and that growth is the accumulation everyone then tries to drain by care.

For this reason, above one tier, scale is reduction, with fused results going up, scope coming down, and every record keeping one writer. The fused result is published rather than the raw records, at every tier. In practice, the surfaces are arranged as a tree once one tier is not enough. A parent hands scope down and publishes only the fused result of its children upward, and every record keeps its one writer at every depth, so identity and reduction hold unchanged whether the tree is two levels or ten. Each reduction is derivable and checkable, so a fusion that silently drops a live item fails exactly as a dropped record does. Where the reduction step is unbuilt, it is declared so, rather than letting a design read as if it had been measured at a headcount it never reached.

To check this, take any surface above the first tier and ask what it publishes upward. If it forwards raw records, it is accumulating by construction, and no drain rule will keep up with it. Reduction changes what is published upward and never who may write. A parent that rewrites a child's record has taken a second writer's seat, and a child that reads the global view has bypassed the bound that made its reading finite. The tree holds only while both stay on their side.

### Fan-in taken seriously

Reduction is [fan-out/fan-in](https://banes-lab.com/records/arch/fan-out-fan-in.md) with the fan-in half taken seriously. Fan-out is cheap, because scope handed down divides. Fan-in is where every distributed design pays, because results handed up add, and the only way to keep the sum bounded is to reduce at each tier. [Orchestration](https://banes-lab.com/records/arch/orchestration.md) is the shape of one tier, a coordinating owner that hands scope down and publishes one fused result up, and [choreography](https://banes-lab.com/records/arch/choreography.md) is the shape between peers who share no parent.

Branching is fractal, running from workers into an orchestrator, into another orchestrator and into a composer. Every record keeps its one writer, and a reduced tier is published by one writer, so identity and reduction hold unchanged at any depth. A [message chain](https://banes-lab.com/records/arch/message-chain.md), one party relaying another's raw record to a third, is the anti-pattern that appears the moment a tier forwards rather than reduces.

### Checkable, and honestly unmeasured

A reduction is derived and checkable, and a fusion that silently drops one live item beneath it fails exactly as a dropped record does. [Missing backpressure](https://banes-lab.com/records/arch/missing-backpressure.md) is the same defect at a queue, where a tier that accepts more than it reduces accumulates, and the accumulation is the design working as built.

The reduction step itself is declared unbuilt and unmeasured at any headcount, and saying so is what stops the design reading as though it had been measured. A design that claims [scalability](https://banes-lab.com/records/arch/scalability.md) it has not measured makes, in prose, the unevidenced claim the coverage tab refuses.

C1·a reduction

```mermaid
flowchart TB
w1["worker"] --> o1["orchestrator · publishes the fused result of its workers"]
w2["worker"] --> o1
w3["worker"] --> o2["orchestrator"]
w4["worker"] --> o2
o1 --> composer["composer · one writer, one reduction"]
o2 --> composer
raw["Raw records passed upward · fan-in without reduction, accumulation by construction"]
o1 -. never .-> raw
```

## Links to

- [Fan-out/Fan-in](https://banes-lab.com/records/arch/fan-out-fan-in.md)
- [Orchestration](https://banes-lab.com/records/arch/orchestration.md)
- [Choreography](https://banes-lab.com/records/arch/choreography.md)
- [Message Chain](https://banes-lab.com/records/arch/message-chain.md)
- [Missing Backpressure](https://banes-lab.com/records/arch/missing-backpressure.md)
- [Scalability](https://banes-lab.com/records/arch/scalability.md)