For filters connected by pipes in a message-processing pipeline to be truly reusable and composable — droppable into different pipelines without rewriting them — what do they need to agree on, and what breaks that reusability in practice?

## Where reusability comes from Reusability in Pipes and Filters comes entirely from the fact that a filter's only dependency is the **message contract** flowing through the pipes it's attached to — the schema, serialization format, and agreed semantic meaning of the data — never any specific neighboring filter's code or deployment. A filter is reusable if you can lift it out of pipeline A and drop it into pipeline B, with different neighbors on both sides, and it still behaves correctly because both pipelines carry messages that satisfy the same contract on its input pipe and expect the same contract on its output pipe. This is the whole point of the pattern: a `deduplicate-by-id` filter, a `validate-against-schema` filter, or a `redact-PII-fields` filter written once should be pluggable into any pipeline whose messages carry an id, a schema, or PII fields respectively, without modification. ## What breaks it in practice What breaks this in practice is almost always an implicit dependency sneaking in disguised as an explicit one. - The most common failure is a filter assuming state that a specific upstream neighbor establishes but that isn't actually part of the message contract — for example, a `send-notification` filter that assumes 'by the time I see this message, it has already been deduplicated,' when deduplication isn't actually guaranteed by the contract, just by the accident of which pipeline it happened to be plugged into last time. Move that filter into a new pipeline that doesn't happen to run a dedup filter first, and it silently sends duplicate notifications — a bug caused entirely by an unstated assumption, not by any code change in the filter itself. - Another common break is **uncoordinated schema evolution**: if a producer starts adding a new required field, or renaming/removing a field a filter reads, every consumer of that message shape can break simultaneously, at different times, in different pipelines, which is much harder to trace than a compile error in a monolith because the break is discovered only when a specific message shape reaches a specific filter in production. ## Contract-first design with versioning The standard mitigation is **contract-first design with explicit versioning**. 1. Concretely: define the message shape as a schema (JSON Schema, Avro, Protobuf, or similar) that is itself a first-class, versioned artifact — not just 'whatever the last filter happened to produce.' 2. Filters declare which version(s) of the schema they can consume, and schema changes follow compatibility rules (e.g., only additive, optional fields for a 'minor' change; a new topic/version for a breaking change) so old and new filters can coexist during a rollout. 3. A schema registry (used heavily with Kafka via Avro/Protobuf schema registries, similarly available for Service Bus/Event Grid patterns on Azure) enforces this at write time — a producer can't publish a message that violates the registered schema, and consumers can pin to a compatible version. This turns the 'silent coupling' failure mode into a build-time or publish-time error instead of a runtime surprise. ## Minimal field coupling A second, subtler discipline is **minimal field coupling**: a well-designed filter should only read the specific fields it needs to do its job, not the entire message envelope, and should pass through fields it doesn't understand unchanged rather than dropping them. A filter that reads 'the whole blob and re-serializes only the fields it recognizes' silently strips any field added later by an upstream producer it wasn't updated to know about — breaking any downstream filter that needed that field, even though nothing about the schema technically changed incompatibly. This is analogous to Postel's robustness principle applied to pipeline stages: - be liberal in what you pass through unmodified - conservative in what you claim ownership of and transform. ## The same schema, two pipelines A concrete real-world illustration: an e-commerce order-processing pipeline has a canonical `OrderEvent` schema on its central bus. A `fraud-score` filter reads only the payment-method and amount fields to compute a risk score and passes the rest of the message through untouched; because it depends on nothing but those two fields being present per the schema, it can be reused unchanged in a completely different pipeline (say, a returns-processing flow) that also emits messages conforming to the same OrderEvent schema — as long as that schema's payment-method and amount fields mean the same thing in both contexts. If a new pipeline redefined 'amount' to mean pre-tax instead of post-tax without a schema version bump, the fraud-score filter would silently miscompute risk in that context despite 'working' with no errors — the canonical example of a broken contract, not a broken filter.