외부 서비스가 죽었을 때를 대비하는 프롬프트

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.