A travel platform integrates hundreds of suppliers, each with different APIs, latencies, reliability and data quality. How should modularity be applied, and what specifically goes wrong in platforms that get this boundary wrong?

The shape of the problem

Supplier count grows without bound. Each supplier is individually unremarkable and collectively the dominant source of complexity. Peculiarities leak: one returns prices excluding tax, one paginates inconsistently, one is fast but frequently wrong, one is slow but authoritative, one rate-limits by IP.

The decomposition that works

A supplier adapter per supplier, behind one internal contract. The contract expresses what the platform needs — availability, price with a defined tax treatment, cancellation terms, a booking handle — not the union of what suppliers offer. Adapters are independently deployable and are the only code allowed to know a supplier's name.

A per-supplier reliability profile as data. Timeout, retry budget, concurrency ceiling, circuit state and freshness tolerance are configuration attached to the adapter, not constants in the aggregator. A slow supplier becomes a tuning change, not a code change.

An aggregation layer that treats suppliers as optional. Fan out in parallel, apply a global deadline, return whatever arrived. Partial results are the normal case, not the error case.

A reconciliation path separate from search. Search may be wrong; the booking step re-validates against the supplier of record. Different correctness requirements, therefore different modules.

What goes wrong when the boundary is wrong

1. The god-aggregator. Supplier-specific branches accumulate in shared code; every integration change risks every other supplier and change cost grows superlinearly with supplier count.
2. The slowest supplier sets the latency. Without per-supplier isolation one degraded supplier holds threads across the whole fan-out and search latency becomes the max rather than the deadline. This is the classic aggregation cascade.
3. The over-generalised contract. Modelling the union of all supplier capabilities means the contract changes whenever any supplier changes — the opposite of modularity.
4. Silent data-quality laundering. An adapter quietly defaulting a missing field turns a supplier problem into a platform problem nobody can attribute.

The test of a good boundary

Adding supplier 301 should be bounded, repeatable work by one team, with no change to the aggregation layer and no risk to suppliers 1 through 300. If it is not, the boundary is decorative.