Engineering · 2026-04-13
Circuit Breakers for Identity Pipelines: Graceful Degradation When a Carrier API Goes Dark
By J. W. Bouckaert
Carrier API failures
An identity check that depends on a carrier API assumes the API will answer within the time the check allows, with accurate data. That assumption fails from time to time.
A carrier data provider such as Twilio Lookup v2 or Vonage Number Insight often depends on other parties to answer: carrier interconnects, aggregators and the carrier's own systems. A failure at any of them can delay or break the answer, and the identity pipeline has to decide what to do while it waits.
The usual answer is a timeout and a retry. This article explains where that falls short, how the circuit breaker pattern works, and what PasskeyBridge's carrier lookup does when its provider fails.
Limits of timeouts and retries
The standard approach to carrier API resilience looks like this:
Request → Timeout (5s) → Retry → Timeout (5s) → Retry → Fail → Return errorThis pattern has three problems that compound during real outages:
1. Latency accumulation
If your per-provider timeout is 5 seconds and you retry twice, a single failing provider adds 15 seconds to every verification request. For a sign-in or payment flow that waits on the check, a 15-second delay has the same effect on users as an outage.
2. The retry storm
When a carrier API is struggling under load, retries from every client make the problem worse. If 10,000 concurrent verifications each retry twice against a degraded provider, the provider receives 30,000 requests instead of 10,000. This is the retry storm antipattern: the retries add load to a provider that is already failing.
3. Binary failure mode
Timeout-and-retry produces a binary outcome: success or failure. A PasskeyBridge lookup has that shape, because it asks one provider. A failed call is a failed lookup. Single-provider lookups explains which provider a call asks.
The circuit breaker pattern
The circuit breaker pattern, formalized by Michael Nygard in Release It! (2007) and adopted across distributed systems since, addresses the first two problems by moving failure detection from each request to the provider as a whole. It does not remove the third: when the only provider is unavailable, the check still has no answer.
A circuit breaker monitors the health of an upstream dependency over a rolling window of requests. When failures exceed a threshold, the breaker opens and blocks all requests to that provider without waiting for timeouts. After a cooldown period, the breaker transitions to half-open and probes the provider with a single request. If the probe succeeds, the breaker closes and normal traffic resumes. If it fails, the breaker reopens.
State machine
| State | Behavior | Transition Trigger |
|---|---|---|
| Closed | All requests forwarded normally | Error rate exceeds threshold → Open |
| Open | All requests short-circuited (no network call) | Cooldown timer expires → Half-Open |
| Half-Open | Single probe request forwarded | Probe succeeds → Closed; Probe fails → Open |
Netflix's Hystrix popularized the pattern for microservices; it has been in maintenance mode since 2018, and its README points new projects to Resilience4j. Polly provides it for .NET.
Carrier lookup when the provider fails
shield-carrier-lookup asks one provider. When that provider times out or returns an error, the lookup fails. There is no second provider on the same request, no weight to redistribute, no minimum trust threshold, and no half-open probe of a carrier API.
The predictive ladder has its own breaker on the ladder's gateway. That breaker is not a carrier-provider weight, and it does not run inside the lookup.
A tenant that wants a different provider sends another lookup naming that provider, or registers the Vonage application or Sinch project the unnamed lookup already prefers. Ingest and playbooks still run when the signal arrives by webhook. The carrier call and the playbook are separate requests.
Identity signals documents the lookup. Single-provider lookups describes which provider a call asks.