Third-party API failures: designing for dependencies you don’t control
Payment providers, email services, identity providers and AI model APIs fail and throttle independently of your system. Their failures become yours unless you design for them.
What causes it
A synchronous call to a third party puts its availability and latency directly on your critical path. If it returns errors 10% of the time, 10% of your requests fail; if it slows down, your servers hold resources while they wait.
How to recognise it
- Errors with the provider’s own codes in your logs
- Your error rate tracking the provider’s status page
- Latency spikes that match the provider’s response times
How to fix it
- Retry with back-off
- Add a circuit breaker and a fallback
- Queue work so it can be retried later
Reproduce it in the simulator
Open the simulator, build a small architecture and use Fault injection in the inspector, or push traffic past a component’s capacity.
Learn more
Part of the guide Message queues vs event streams.