初級では「同じ部品の組み合わせ方が違うだけ」と捉えました。中級では、サービスの性質が要求する設計パターンを見ます。
中級の解説は準備中のため、中級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
読み中心か、書き中心か
- 読みが多い(SNSのタイムライン・記事) — キャッシュ、CDN、DBのリードレプリカで読みを分散
- 書きの正しさが重要(決済・在庫) — トランザクションで整合性を守る。安易にキャッシュしない
- リアルタイム(チャット・通知) — WebSocket/SSE でつなぎっぱなしに
通常のHTTPは「お願い→返す」の都度接続なので、更新が起きても聞くまで届きません。サーバから更新を押し出すには、つなぎっぱなしのWebSocket(双方向)やSSE(サーバ→クライアントの一方向push)を使います。
アニメーション『リアルタイム通信(WebSocket/SSE)』を開く
SNSのタイムラインは「いつ配るか」で設計が分かれます。投稿時に各フォロワーへ配る(読みが速い)か、読むときに集める(書き込みが軽い)かのトレードオフです。
アニメーション『タイムラインの配り方(fan-out)』を開く
登場人物メモ:
- ※1 リードレプリカ — 読み取り専用のDB複製。読みを逃がす
- ※2 WebSocket — つなぎっぱなしの双方向通信
具体例で見る
- チャット — WebSocketで双方向、メッセージはDB+キャッシュ、既読/通知はキュー
- 動画配信 — アップロードは署名付きURLでストレージへ、変換はキュー、配信はCDN、視聴履歴はDB
- ネットショップ — 商品はCDN/キャッシュ、在庫・注文はDBのトランザクション、決済は外部API、確定処理はキュー
パターンの見取り図
- スケール — ステートレス+ロードバランサで水平に。状態はDB/キャッシュへ
- 整合性 vs 速さ — 強整合が要る所(在庫・残高)と、多少古くてよい所(タイムライン)を分ける
- 障害設計 — 単一障害点を避け、リトライ・タイムアウト・フォールバックを用意
- 外部依存 — 決済・地図・通知などは外部APIに委ね、失敗時の扱いを決めておく
⚠️ つまずきどころ
- 何でもキャッシュ — 在庫や残高をキャッシュして二重販売・不整合
- 同時実行の見落とし — レースコンディション(在庫・ポイント)
- 外部API頼み — 決済APIが落ちたときの設計が無い
- リアルタイムの過負荷 — 接続数の増加に耐える設計(水平分割)が要る
理解度チェック
そのまま解けます(成績は保存されません)。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. ネットショップで「在庫1個を2人が同時に買う」を正しくさばくのに必要なのは?
問2. チャットの「相手の発言がリアルタイムに届く」を実現する代表的な仕組みは?
問3. 複数の処理が同時に走り、実行の巡り合わせで結果が変わってしまう問題を何と呼ぶ?
問4. サーバからクライアントへの一方向のリアルタイムpush(通知の配信など)に向く仕組みはどれ?
問5. 動画配信サービスで、大きな動画ファイルをブラウザからストレージへ直接アップロードさせるのに使うのはどれ?
問6. 在庫や残高を安易にキャッシュすると起きやすい問題はどれ?
問7. サーバを並べて負荷を分散する「水平スケール」の前提となる設計はどれ?
問8. 読み取り専用のDBの複製を用意して読みの負荷を逃がす仕組みを、カタカナで何と呼ぶ?