他人の家のブレーカーが
落ちて停電
「便利だから」という理由で導入した外部API。
ある日、そのAPIがダウンしただけで、
なぜあなたのサイトのトップページまで真っ白になるのでしょうか？
- 外部APIを呼ぶ処理に「タイムアウト（Timeout）」を設定していない
- 天気予報や株価など「おまけ情報」の取得失敗で、メイン画面がエラーになる
- API呼び出しを「同期処理（Synchronous）」で行っている
- 「GoogleやTwitter（X）が落ちるはずがない」と信じている
SPOF（単一障害点）を外部に委ねる自殺行為です。
01. 運命共同体の罠
システム開発において、外部サービス（SaaS/API）の利用は不可欠です。
しかし、それは「自社でコントロールできない不確定要素」をシステムに組み込むことを意味します。
連携先がメンテナンス中だったり、DDoS攻撃を受けていたりした場合、あなたのシステムはそれを「無視」できますか？
それとも、一緒に待ち続けて「共倒れ」しますか？
これがシステム間連携における唯一の正解。
最も愚かなのは、トップページの表示処理の中で、外部APIに対して同期リクエスト（レスポンスが返ってくるまで処理を止めて待つ）を送ることです。
たかが「今日の天気」を表示するために、大事な「商品購入ボタン」の表示まで道連れにしてはいけません。
02. 自分だけでも生き残れ
外部システムのダウンに引きずられないために、フェイルセーフ（安全装置）を組み込む必要があります。
Pattern A: サーキットブレーカー（Circuit Breaker）
家のブレーカーと同じです。外部APIへの接続エラーが一定回数・一定割合を超えたら、自動的に「スイッチ（回路）」を遮断（Open）します。
遮断中は、そもそもAPIにリクエストを送らず、即座にエラーまたは代替コンテンツ（キャッシュデータなど）を返します。
これにより、システム全体がタイムアウト待ちで詰まるのを防ぎます。
Pattern B: 徹底的な非同期化
画面表示（レンダリング）に関わるメインスレッドで、外部通信をしてはいけません。
外部データ取得はバックグラウンドの非同期ジョブ（Worker）で行い、結果をDBやキャッシュに保存。
画面表示時は、そこから読み出すだけにします。
これなら、外部が死んでいても「データが古い」だけでシステムは動き続けます。
03. 依存のリスクを可視化せよ
アーキテクチャ図を見直し、システム外への矢印が何本あるか数えてください。
その矢印のすべてに「ハサミ（遮断機能）」はついていますか？
依存を断ち切る勇気を持つことが、可用性向上の第一歩です。