理Kotowary

サービス別の構成例 — 同じ部品の組み合わせ方

大人こども
初級中級上級

概要 — まず全体をつかむ

中級ではサービスの性質と設計パターンを見ました。上級では、実サービスの構成を、具体的な難所とともに。

詳細 — 1段階ずつ追う

SNS／タイムラインの構成

  • 配信方式 — fan-out on write（投稿時に各受信箱へ）／on read（表示時に集約）。有名人問題ではハイブリッド
  • 読みの分散 — タイムラインは強くキャッシュ、DBはリードレプリカ
  • イベント駆動 — 通知・集計・検索インデックス更新は非同期
  • 整合の見せ方 — 自分の投稿は即見える（楽観的UI）、他人分は少し遅れてよい
やさしく言うと（中級）
  • 読みが多い（SNSのタイムライン・記事） — キャッシュ、CDN、DBのリードレプリカで読みを分散
  • 書きの正しさが重要（決済・在庫） — トランザクションで整合性を守る。安易にキャッシュしない
  • リアルタイム（チャット・通知） — WebSocket／SSE でつなぎっぱなしに

通常のHTTPは「お願い→返す」の都度接続なので、更新が起きても聞くまで届きません。サーバから更新を押し出すには、つなぎっぱなしのWebSocket（双方向）やSSE（サーバ→クライアントの一方向push）を使います。

アニメーション『リアルタイム通信（WebSocket/SSE）』を開く
リアルタイム通信の3方式① 通常のHTTP（ポーリング）クライアントサーバ① お願い（リクエスト）② 返す（レスポンス）③ また最初から…（都度接続）更新が起きても、こちらが「聞く」まで届かない（毎回つなぎ直す）② WebSocket（双方向・開きっぱなし）クライアントサーバ送る →← 送る一度つなげば、どちらからでも即プッシュできる（双方向）③ SSE（サーバ→クライアントの一方向push）クライアントサーバ更新① を push更新② を push更新③ を pushサーバが更新を一方的に押し出す（クライアント→サーバの送信はできない）更新をサーバから届けたいときは WebSocket ／ SSE

SNSのタイムラインは「いつ配るか」で設計が分かれます。投稿時に各フォロワーへ配る（読みが速い）か、読むときに集める（書き込みが軽い）かのトレードオフです。

アニメーション『タイムラインの配り方（fan-out）』を開く
fan-out on write（書く時に配る）投稿時に配っておく投稿者1回投稿受信箱フォロワー毎受信箱フォロワー毎受信箱フォロワー毎読むとき速い ⇔ 書き込みが重い（配る先が多い）fan-out on read（読む時に集める）読むとき集めて作る投稿フォロー相手投稿フォロー相手投稿フォロー相手閲覧者読む時に要求書き込みが軽い ⇔ 読むときが重い（毎回集める）大量フォロワーの有名人は「読み時に集約」が定石（配る先が多すぎるため）

登場人物メモ:

  • ※1 リードレプリカ — 読み取り専用のDB複製。読みを逃がす
  • ※2 WebSocket — つなぎっぱなしの双方向通信

ネットショップの構成

  • 在庫の同時実行 — 楽観／悲観ロック、原子的減算で超過販売を防ぐ
  • 決済 — 外部APIに委任＋冪等キーで二重課金防止＋サーキットブレーカ
  • 注文フロー — 複数サービスをまたぐのでSagaで整える
  • 検索 — DBの外に全文検索／検索エンジンを置く（DBのLIKEは重い）
やさしく言うと（中級）
  • チャット — WebSocketで双方向、メッセージはDB＋キャッシュ、既読/通知はキュー
  • 動画配信 — アップロードは署名付きURLでストレージへ、変換はキュー、配信はCDN、視聴履歴はDB
  • ネットショップ — 商品はCDN/キャッシュ、在庫・注文はDBのトランザクション、決済は外部API、確定処理はキュー

横断するパターン

  • イベントソーシング／CQRS — 変更を events として蓄え、読み取り専用のリードモデルを作る
  • リードモデル — 表示に最適化した非正規化ビュー（結果整合で更新）
  • 外部依存の隔離 — 決済・地図・通知の障害を、タイムアウト／フォールバックで閉じ込める
  • マルチリージョン — 近さと可用性のため、データの分散と整合を設計
やさしく言うと（中級）
  • スケール — ステートレス＋ロードバランサで水平に。状態はDB/キャッシュへ
  • 整合性 vs 速さ — 強整合が要る所（在庫・残高）と、多少古くてよい所（タイムライン）を分ける
  • 障害設計 — 単一障害点を避け、リトライ・タイムアウト・フォールバックを用意
  • 外部依存 — 決済・地図・通知などは外部APIに委ね、失敗時の扱いを決めておく

⚠️ 実サービスの難所

  • 有名人問題 — fan-outの偏り、ホットキー
  • 二重課金 — 決済の冪等性・整合
  • 超過販売 — 在庫の競合制御漏れ
  • 結果整合の体験 — 「反映が遅い」をUIでどう見せるか（楽観的更新と巻き戻し）
やさしく言うと（中級）
  • 何でもキャッシュ — 在庫や残高をキャッシュして二重販売・不整合
  • 同時実行の見落とし — レースコンディション（在庫・ポイント）
  • 外部API頼み — 決済APIが落ちたときの設計が無い
  • リアルタイムの過負荷 — 接続数の増加に耐える設計（水平分割）が要る

理解度チェック

そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。

問1. SNSのタイムラインで「投稿時に各フォロワーの受信箱へ配っておく」方式は？

問2. ネットショップで在庫1個を同時購入させないための代表策は？

問3. 決済を外部APIに委ねるとき、通信の再送などで同じ支払いが二重に実行されるのを防ぐ仕組みはどれ？

問4. 注文のように複数サービスをまたぐ一連の処理を、途中失敗も含めて整合させる代表的な手法は？

問5. フォロワーが超多数の有名人アカウントで fan-out on write（投稿時に各受信箱へ配る）が問題になるのはなぜ？

問6. 変更を events として蓄積し、そこから読み取り専用のモデルを組み立てる設計パターンは？

問7. 決済など外部依存が連続して失敗したとき、呼び出しを一時的に遮断して被害の連鎖を防ぐ仕組みをカタカナで何と呼ぶ？

問8. 表示に最適化して非正規化した、読み取り専用のビュー（結果整合で更新される）を何と呼ぶ？