Plan for an external dependency going down
Works out what happens to your system when each third-party service stalls.
| Category | Development › Deploy & operations |
|---|---|
| Tags | AnalyzingReviewingDeveloper |
Plan for each of these dependencies failing. Per dependency, three failure modes — they behave very differently: - **Hard down** — errors immediately - **Slow** — responds eventually. *This is the dangerous one: threads pile up waiting and the whole system stalls, which looks like our failure, not theirs.* - **Wrong** — responds successfully with bad data For each mode: 1. What breaks on our side, and whether it stays contained or spreads. 2. Whether we fail open or closed, and which is correct here. For a payment check, failing open is a loss; for a recommendation, failing closed is a worse experience. 3. Timeout and retry setting. Retries during a dependency outage amplify the outage — say whether backoff and a circuit breaker are needed. 4. Whether a cached or stale response would serve, and how stale is acceptable. 5. What the user sees. Then: - Which dependency is on the critical path for the core action, and whether it should be. - Dependencies that are single points of failure for our stated availability commitment. *If any third party has lower availability than we promise, we cannot meet our own number* — say so plainly. - What to test, and how to simulate each mode.
After pasting, fill in the fields at the bottom (Dependencies · System · Availability commitment)
What this prompt does
Someone else's service will fail eventually. This traces the consequence per dependency, with particular attention to the silent case where everything merely gets slower.