Resilience at the vendor edge

Every modern stack ends at someone else’s API. Payments, identity, tax, search, email, shipping, model inference — a typical estate calls dozens of vendor systems, and every one of those calls is a point where someone else’s outage can become yours.

The engineering playbook for surviving vendor failure is well understood, and most of it lives in one place: the calling edge, where your code meets their API. What most organizations lack is not the playbook. It is the ability to answer three questions about their own estate: where are all the vendor edges, which protections does each one have, and which paths from a user’s screen to a vendor system are exposed.

This post covers both halves — the controls that belong at the edge, and how to make compliance against them visible across a whole estate.

The controls that belong at the calling edge

Resilience at the vendor edge protects three parties at once. It is worth being explicit about all three, because teams routinely implement the first and forget the other two.

Protect your own systems. A vendor that stops answering should cost you one failed call, not a service.

• Timeouts on every call — and a latency budget across the chain, so five generous timeouts don’t stack into a request that hangs for a minute
• Circuit breakers — after repeated failures, fail fast instead of queueing more requests behind a dead dependency
• Bulkheads — give vendor-facing calls their own connection and thread pools, so a slow vendor drains its own compartment rather than the whole service
• Idempotency keys on writes — so a retry after an ambiguous failure is safe to send

Protect the vendor. This one is under-practised, and it is the difference between an outage and a long outage. When a vendor recovers, the worst thing its customers can do is arrive all at once.

• Retries with exponential backoff and jitter — naive retry loops become a coordinated storm that keeps a recovering service down
• Client-side rate limiting — honour the contract you signed, including 429 and Retry-After, before their edge has to enforce it
• Request coalescing — one in-flight request per identical query, not one per waiting caller

Protect the experience. Between “fully up” and “hard down” there is a wide band of degraded service your users will barely notice — if you engineered for it.

• Caching floors — serve the last known good response past its TTL when the vendor is unavailable, within a staleness bound the business has signed off on. Hour-old exchange rates beat no checkout; week-old ones need a different conversation
• Fallbacks — a default, a secondary provider, or a reduced feature in place of an error page
• Queued writes — accept the user’s action, queue it, and deliver when the vendor returns
• Feature shedding — a flag that turns the dependent feature off cleanly, so the rest of the product carries on

None of this is novel. Timeouts, breakers, backoff and floors have been written up for a decade. The gap is elsewhere.

Why this fails at estate scale

Resilience is implemented per codebase, by the team that owns the service. Whether it happened — and to what standard — is knowable only by reading that code. So the estate-level questions go unanswered:

• Which of our vendor edges have no circuit breaker?
• If the payments vendor goes down at 9am, which front-ends degrade, and which break?
• Which edges gained a new vendor dependency this quarter?

Architecture reviews audit one service at a time. The spreadsheet from the last resilience push was accurate for a month. And the number of vendor edges only grows — every new feature seems to arrive with an API key — which means the audit you ran last year describes an estate that no longer exists.

This is an inventory problem. The controls live in code; the visibility has to live somewhere that can see across all of it.

Model the edge, not just the boxes

The usual landscape diagram draws services and vendors and stops there. The thing you audit, though, is the edge — and in an Aplas inventory the edge is already a record. Any asset type can declare that its records connect sources to targets; the built-in Integration is exactly that — one or more sources, one or more targets, a verb, and fields of its own. Out of the box its endpoints point at applications; widen the field’s Points at to take in your vendor-system type and the estate’s boundary is in the model too.

So the resilience audit doesn’t need a new concept. It needs fields on the record that already exists — added the same way you may already have added a protocol or a data classification, because built-in types take custom fields like any other:

Field	Values
Timeout budget	set / unset
Retry policy	backoff + jitter / naive / none
Circuit breaker	yes / no
Client rate limiting	yes / no
Caching floor	last known good / read-through / none
Fallback	provider / degraded feature / queued / none
Resilience rating	protected / partial / exposed

The rating rolls the controls up into one word a review can act on. Use whatever rubric your reliability forum agrees on — the point is that it is recorded per edge, in one place, beside the estate it describes.

Every integration carries the fields, not just the vendor ones. That is deliberate: an internal hop nobody has graded is itself a finding — the first pass over this worked example left a grey band of unrated integrations, and each one is a question with an owner. Relationship types stay semantic — the built-in depends on at the vendor boundary, a calls verb you add for the hops between your own systems — and the grade lives with the other facts about the edge.

When one edge is really a chain — front-end to gateway to adapter to vendor — the integration can say so: a connection lists its internal steps, each hop with its own verb, and the views draw the sequence. “The exposed path” stops being a figure of speech.

You don’t build this by hand from a blank page. Drop in the spreadsheet from your last audit and the AI maps it onto the connection types you already have — sources, targets and control fields matched to the existing model rather than a new type invented per sheet — laid out for you to confirm.

See the exposed paths

Because the grade is a field on the edge, every view of the inventory picks it up.

The flow view draws the blast radius. Front-ends on the left, vendors on the right, every service hop between, laid out by depth — each ribbon’s width carrying how many integrations run through it (or any numeric field: a count today, a traffic figure tomorrow), its colour carrying the resilience rating. This is the picture every resilience conversation needs: follow checkout traffic left to right, and the red ribbon into the payments vendor is an argument nobody needs to make twice. The grey ribbons are the unrated edges — visible precisely because nobody has answered for them yet.

The blast radius, published: 199 integrations across a 40-application estate, flowing to twelve vendors — ribbons weighted by traffic, coloured by rating.

The matrix is the scorecard. Filter to the depends on integrations, place them in cells by vendor and rating, and you have the compliance grid for the quarter: which vendors sit behind protected edges, which column of “exposed” needs a sprint. Colour by count and the hot spots find themselves.

Vendor × rating, filtered to the vendor boundary. The exposed column is the quarter’s work.

The table is the punch list. Filter the integration grid to rating = exposed, sort by what sits above it, and export it exactly as shown to Excel — that spreadsheet is the reliability review’s agenda, regenerated from live data instead of maintained by hand. With protocol, data classification and traffic on the same record, the row that reads PII · 2.6M requests a day · no timeout · no breaker · no floor prioritises itself — and it isn’t even a vendor edge.

The punch list: 28 exposed integrations — vendor edges and internal hops alike — with live traffic beside the missing controls.

Publish it, and the audit stops being a document. Each of those views publishes on its own — to the architecture guild, to the reliability forum, or to everyone in the organization. The graph your incident review looks at in November is the same one it looked at in June, showing what changed rather than what someone last remembered to update.

Start with one vendor

Nobody grades three hundred edges in a week, and nobody needs to. Pick the vendor whose outage would hurt most. Inventory its edges, record the controls, grade them, and publish the flow view. The first red ribbon sitting under a customer-facing path usually settles the prioritisation debate on its own.

The demo workspace shows the shape of an inventory like this — applications, integrations and the views over them — without signing up. To build yours, start on the Free plan and bring the audit spreadsheet you already have. The getting started guide covers the inventory, modelling connections, the flow view and publishing.