Dependency and Connectivity Design for Hard Integrations

Why this matters

A payment provider has a bad hour and the checkout hangs for every user instead of degrading: no timeout, no fallback, threads piling until the whole service falls. The provider recovered; the service stayed down from the pileup. Dependency failure is normal and scheduled by nobody; the design decides whether it degrades one feature or the whole system. Every hard integration needs its failure designed before its success is celebrated.

Concepts

The dependency map lists each external: owner, contract (API, SLA, limits), failure modes (slow, wrong, absent), and the blast radius if it fails. Timeouts bound every call (M18's deadline returns); fallbacks define degraded behavior per dependency (cached data, queued writes, disabled feature with a clear message); bulkheads isolate pools so one slow dependency cannot consume all threads. Each row of the map carries all three, or the row is a hope.

Contracts let both sides change. Versioned APIs, deprecation notice periods, schema compatibility rules (M14's expand/contract at organizational scale), and shared staging verification before either side ships breaking changes. The contract is a document both teams sign, with a named owner per side; handshake agreements expire with the people who shook on them.

Drills rehearse absence. Fault-inject the dependency (slow, wrong, absent) in staging on schedule and watch degradation engage: timeouts fire, fallbacks serve, bulkheads hold, alerts name the dependency. The drill that never runs teaches nothing; the drill that fails teaches the next design iteration. Records quote the degraded behavior, not the hope of it.

Worked example

A fixture checkout depends on a fixture payment service. The learner maps it (owner, contract, failure modes), sets timeout plus cached fallback plus isolated pool, then faults the dependency three ways and quotes graceful degradation each time. The map, the bounds and the drill results form the integration's design record.

Common wrong move

Treating the dependency's status page as the reliability plan. Their uptime is their business; your behavior during their downtime is yours. Design the failure, drill it, document it, or inherit it unprepared.