👋
依存する外部サービスの障害時の影響を考慮しているか？
依存する外部サービスの障害時の影響を考慮しているか？
背景・概要
外部サービス（SaaS、API、DB）の一時的な障害は前提条件にすべき
外部依存を想定しない設計は障害耐性のない脆弱なシステムになりがち
例
- レスポンスがなければタイムアウト＆リトライ（例：3回、指数バックオフなど）
- 非同期ジョブにしてバックグラウンドで再送を試みる
- 外部APIがダウンしたら「後で再試行」のバッファに保存して任意のタイミングで再実行
よくある失敗例
- 外部APIエラーで画面が白くなってユーザーが操作不能
- APIが止まるとジョブ全体が停止して処理が詰まる
- スロットリング制限で大量の429エラーが発生し、復旧不能になる
FAQ
Q. 外部APIが止まったらどうするのが正解？
A. ユースケース次第だが、重要でなければ保留・再試行に切り替え、重要ならフェイルオーバー（代替経路への切り替えやキャッシュによる過去データ表示など）を用意する
Q. SLAが低い外部サービスは使ってよい？
A. 使ってよいが、依存を弱く保ち障害時に逃げ道がある構造にするのが前提。リトライ・フェールセーフは考慮必須
関連観点
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：🔁 イベント・非同期処理
レベル：Structure（構造・原則・責務整理レベル）
推奨読者：設計初心者 / 設計中のチーム / レビュワー
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion