中級ではサービスの性質と設計パターンを見ました。上級では、実サービスの構成を、具体的な難所とともに。
上級の解説は準備中のため、上級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
SNS／タイムラインの構成
- 配信方式 — fan-out on write（投稿時に各受信箱へ）／on read（表示時に集約）。有名人問題ではハイブリッド
- 読みの分散 — タイムラインは強くキャッシュ、DBはリードレプリカ
- イベント駆動 — 通知・集計・検索インデックス更新は非同期
- 整合の見せ方 — 自分の投稿は即見える（楽観的UI）、他人分は少し遅れてよい
ネットショップの構成
- 在庫の同時実行 — 楽観／悲観ロック、原子的減算で超過販売を防ぐ
- 決済 — 外部APIに委任＋冪等キーで二重課金防止＋サーキットブレーカ
- 注文フロー — 複数サービスをまたぐのでSagaで整える
- 検索 — DBの外に全文検索／検索エンジンを置く（DBのLIKEは重い）
横断するパターン
- イベントソーシング／CQRS — 変更を events として蓄え、読み取り専用のリードモデルを作る
- リードモデル — 表示に最適化した非正規化ビュー（結果整合で更新）
- 外部依存の隔離 — 決済・地図・通知の障害を、タイムアウト／フォールバックで閉じ込める
- マルチリージョン — 近さと可用性のため、データの分散と整合を設計
⚠️ 実サービスの難所
- 有名人問題 — fan-outの偏り、ホットキー
- 二重課金 — 決済の冪等性・整合
- 超過販売 — 在庫の競合制御漏れ
- 結果整合の体験 — 「反映が遅い」をUIでどう見せるか（楽観的更新と巻き戻し）
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. SNSのタイムラインで「投稿時に各フォロワーの受信箱へ配っておく」方式は？
問2. ネットショップで在庫1個を同時購入させないための代表策は？
問3. 決済を外部APIに委ねるとき、通信の再送などで同じ支払いが二重に実行されるのを防ぐ仕組みはどれ？
問4. 注文のように複数サービスをまたぐ一連の処理を、途中失敗も含めて整合させる代表的な手法は？
問5. フォロワーが超多数の有名人アカウントで fan-out on write（投稿時に各受信箱へ配る）が問題になるのはなぜ？
問6. 変更を events として蓄積し、そこから読み取り専用のモデルを組み立てる設計パターンは？
問7. 決済など外部依存が連続して失敗したとき、呼び出しを一時的に遮断して被害の連鎖を防ぐ仕組みをカタカナで何と呼ぶ？
問8. 表示に最適化して非正規化した、読み取り専用のビュー（結果整合で更新される）を何と呼ぶ？