한국어
☰ Categories

Plan for an external dependency going down

Works out what happens to your system when each third-party service stalls.

CategoryDevelopment › Deploy & operations
TagsAnalyzingReviewingDeveloper
Prompt
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.

More in this category

AI Agent Architect — Design Production-Ready Agents in 15 Steps
AI Agent Security Evaluation Checklist
AI Provider Research Expert
AI Trying to Escape the Box
Analyze code scanning security issues and dependency updates if vulnerable