Skip to content

PATTERN Cited by 1 source

Central connector with provider adapters

Intent

Expose one stable integration contract while allowing independently deployed adapters to translate that contract to heterogeneous provider APIs.

Structure

consumers → stable gateway / connector → normalized workflow
                                      ├→ adapter A → provider A
                                      ├→ adapter B → provider B
                                      └→ adapter C → provider C

providers → adapters → normalized async event bus → consumers

The connector owns behavior common to every provider: authentication, authorization, request routing, aggregation, session/correlation state, normalized errors, and policy. Each adapter owns one provider's protocol transformation and capability mapping. An event bus may carry normalized updates after the synchronous setup flow.

Why use it

  • Adding a provider changes an adapter rather than every consumer.
  • A provider-specific failure, rollout, or capacity increase can be isolated to its adapter.
  • Consumers select among comparable capabilities through one contract rather than provider-specific APIs.
  • Central policy and observability apply consistently at the connector boundary.

Bosch L.OS instance

Bosch L.OS runs a Tracking Connector on ECS/Fargate and provider-specific Lambda adapters. The connector handles standardization, routing, response aggregation, session management, and error handling; MSK carries normalized location updates. Bosch reports that this standardized design reduces a provider integration from 2–4 weeks to within 3 days. (Source: sources/2026-08-14-aws-serverless-vehicle-tracking-at-scale-bosch-los-on-aws)

Trade-offs and failure modes

  • The connector can become a control-plane bottleneck or a single compatibility-release queue unless its contract is versioned and its orchestration remains stateless where possible.
  • Normalization can erase provider-specific capability, reliability, or frequency distinctions; retain capability metadata for consumer selection.
  • Adapters need compatibility, contract, and integration tests against provider changes; independent deployment does not remove operational ownership.
  • Asynchronous updates require explicit duplicate, ordering, retry, and replay semantics.
  • A shared connector simplifies governance but may increase its blast radius; provider-specific rate limits, circuit breakers, and dead-letter handling should remain independently observable.
Last updated · 622 distilled / 1,953 read