中級ではAPI・スケール・データアクセスを見ました。上級では、分散システムとしてのバックエンド——部分的に壊れる前提の設計へ。
上級の解説は準備中のため、上級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
分散は「部分故障」との戦い
1台の中では成功か失敗の二択ですが、サービスが分かれると「一部だけ落ちる・遅れる・返事が来ない」 が日常になります。ここが分散システムの本質的な難しさです。
- ステートレス化 — 状態はDB／キャッシュ／トークンへ逃がし、どの台でも処理可能に
- 境界の設計 — サービス分割の粒度、同期呼び出しの連鎖を減らす
壊れても止まらない処理
- タイムアウト — 無限待ちを避ける（呼ぶ側が必ず設定）
- リトライ＋指数バックオフ＋ジッタ — 再送はだんだん間隔を空け、揃えない
- 冪等キー — 二重実行を無害化
- サーキットブレーカ — 失敗が続く相手を一時遮断し、フォールバック
- 分散トレーシング — 1リクエストが複数サービスを跨ぐ様子を追う
一貫性とデータの流れ
- 結果整合性 — 分散では強整合を諦め、少し遅れて揃う設計が多い
- Saga — 複数サービスにまたがる業務を、補償トランザクションで整える（2相コミットを避ける）
- イベント駆動／CQRS — 変更をイベントで伝え、読み取りと書き込みのモデルを分ける
- アウトボックスパターン — DB更新とイベント発行を、取りこぼしなく一致させる
- バックプレッシャ — 過負荷時に受け入れを絞り、雪崩を防ぐ
⚠️ 分散特有の落とし穴
- カスケード障害 — 1つの遅延が連鎖して全体を巻き込む
- リトライストーム — 一斉リトライが相手をさらに潰す
- スプリットブレイン — 分断で「両方が主」になり整合が壊れる
- 可観測性不足 — ログ・メトリクス・トレースが無いと、分散の障害は追えない
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 下流サービスの障害が全体に連鎖するのを止める仕組みは？
問2. リトライで同じ処理が二重に走っても被害が出ないようにする、実務の定番手段は？
問3. 再送のたびに間隔をだんだん空け、しかも複数のクライアントが揃って再送しないようランダムなズレを加える。この組み合わせに最も近いのは？
問4. 複数サービスにまたがる業務を、補償トランザクションで整えつつ2相コミットを避けるパターンは？
問5. 「DB更新」と「イベント発行」を、取りこぼしなく確実に一致させたい。適したパターンは？
問6. 過負荷のとき、受け入れそのものを絞って処理の雪崩（オーバーロードの連鎖）を防ぐ仕組みは？
問7. ネットワーク分断により「両方のノードが自分こそ主（プライマリ）」と思い込み整合が壊れる状態を、カタカナで何と呼ぶ？
問8. 1つのリクエストが複数サービスを跨いで流れる様子を追い、遅延や失敗の箇所を特定する手法を何と呼ぶ？