Filter Composability
The property that makes a pipeline style work — each stage transforms input to output with no shared state, so stages can be reordered, reused and scaled independently.
The style's power comes from a constraint: each filter knows nothing about its neighbours. It reads from an input pipe, transforms, writes to an output pipe. That is what allows stages to be recombined into new pipelines, tested in isolation, and scaled independently according to which is slowest.
What breaks composability, in practice: a filter that depends on a previous stage's side effect; state accumulated across items; and a schema so specific to one pipeline that the stage cannot be reused.
The design consequences that make pipelines robust:
Filters should be idempotent, because at-least-once delivery between stages is the normal case and retries will re-run them.
Backpressure must propagate. A slow filter must slow its upstream rather than accumulating an unbounded buffer — which is the difference between a pipeline that degrades and one that runs out of memory.
Each stage needs its own error handling and dead-letter path, since one bad item should not stop the pipeline.
The style underlies Unix pipelines, stream processing frameworks and most data engineering, which is why its constraints are worth understanding even when the word is not used.