A travel platform aggregates supply from hundreds of partners with wildly different protocols, latencies and reliability. Which integration patterns apply, and what is the most common structural mistake?

The patterns that apply

Adapter per partner. Each partner's protocol quirks live in exactly one place. This is the foundational pattern, and it is what makes partner count scale linearly rather than quadratically.

Canonical model with an anti-corruption layer. Adapters translate into a model expressing what the platform needs — not the union of what partners offer. Downstream services couple to the canonical model, which changes rarely, rather than to partner peculiarities, which change constantly.

Scatter-gather with a deadline. Fan out to many partners in parallel, apply a global budget, return whatever arrived. Partial results are the normal case, not the error case — with hundreds of partners, the probability that all respond quickly is low even when every one is healthy.

Circuit breaker and bulkhead per partner. A degraded partner must not consume threads or budget across the fan-out. Per-partner concurrency limits are the single most important resilience control here.

Cache with explicit freshness semantics. Availability and price are cached for search; both are re-validated at booking against the partner of record.

Reconciliation as a separate path. Search may be wrong; booking may not. Different correctness requirements, therefore different code paths.

The most common structural mistake

Modelling the union of all partner capabilities in the canonical model.

It seems thorough and it destroys the abstraction: the canonical model now changes whenever any partner changes, which is the exact opposite of what an anti-corruption layer is for. Every downstream service must handle fields that apply to one partner. The model becomes a lowest-common-denominator with a long tail of special cases, and adding partner 301 changes code that partners 1 through 300 depend on.

The correct approach is to model what the platform's product needs, and represent genuine partner differences as explicit, queryable capabilities rather than as fields in the core model. A partner either supports free cancellation or it does not; that is a capability flag the product logic consults, not a variant shape of the availability object.

The second mistake

Treating partner differences as noise to be smoothed away. Some differences are real and load-bearing: delivery of confirmations that may never arrive, per-market regulatory identifiers, per-partner throughput ceilings differing by orders of magnitude. An adapter that quietly defaults a missing field turns a partner data-quality problem into a platform correctness problem that nobody can attribute.

Model them explicitly, surface them in telemetry, and let the product decide how to present them.

The test of the architecture

Adding partner 301 is bounded, repeatable work by one team, with no change to the aggregation layer and no risk to partners 1 through 300. If it is not, the boundary is decorative — and the effort of every future integration will grow rather than shrink.