システム設計面接：回答の構造化方法
なぜ良いエンジニアがシステム設計面接に失敗するのか
分散システムを構築したことがあります。本番停止をデバッグしたことがあります。CDNが何かを知っています。それでも「Twitterを設計してください」と言われると、頭が真っ白になります。
問題は知識ではなく構造です。システム設計の質問は意図的に自由回答です。明確なフレームワークがなければ、コンポーネントの間を飛び回り、要件を明確にするのを忘れ、重要な部分をカバーする前に時間切れになります。
面接官はあなたの最終的な図を採点していません。あなたがどう考えるかを見ています：要件を集め、設計を提案し、ボトルネックを特定し、トレードオフについて推論しますか？それがシステム設計面接が実際にテストしていることです。
あらゆるシステム設計面接のための5ステップフレームワーク
ステップ1：要件を明確にする（3〜5分）
何も描く前に、質問をしましょう。これは時間稼ぎの戦術ではありません——最も重要な部分です。
機能的要件 ——システムがしなければならないこと：
- 中核のユーザーアクションは何か？（投稿、読む、検索、フォロー？）
- どのユースケースが範囲外か？
非機能的要件 ——システムがどう振る舞わなければならないか：
- スケール：毎日のアクティブユーザーは何人？読み取り重視か書き込み重視か？
- レイテンシ目標：主要なユーザーアクションに許容できるのは？
- 可用性：アップタイムSLAは？デプロイ中の短い停止を許容できますか？
- 一貫性：強い一貫性が必要か、それとも最終的な一貫性で良いか？
数字を書き留めましょう。「100万人の毎日のユーザー、100:1の読み取り／書き込み比、読み取りのp99 < 200ms」——これはあなたが行うすべてのアーキテクチャの決定を形作ります。
プロンプトが明確に思えてもこのステップを飛ばさないでください。面接官はあなたが質問するかどうかを確かめるために意図的に曖昧さを残します。
ステップ2：スケールを見積もる（2〜3分）
封筒裏の計算があなたの設計を地に足をつけさせます。1000万人のDAUを持つ読み取り重視のシステムの場合：
- ユーザーあたり1日50読み取りを仮定 → 5億読み取り/日 → 1秒あたり約6,000読み取り
- ストレージ：各レコードが1KBで1日1000万件の新しいレコードを保存 → 10GB/日 → 年間3.6TB
これらの数字は、単一のデータベースで済むかシャーディングが必要か、単一のキャッシュノードで十分か、CDN戦略がどうあるべきかを教えてくれます。
ステップ3：ハイレベル設計（10〜12分）
さあ描きましょう。要件を満たす最もシンプルな設計から始めましょう。ほとんどのシステムの良いハイレベル設計には次が含まれます：
- クライアント → APIゲートウェイ → アプリケーションサービス
- データベース ——どのタイプか、なぜか（リレーショナル、NoSQL、時系列）？
- キャッシュ ——何をキャッシュし、なぜか？
- 非同期処理 ——メッセージキューはどこに合うか？
- CDN ——静的コンテンツまたは地理的に分散した読み取り用
例えば、スケールでのURL短縮サービス：
- **書き込みパス：**クライアント → API → アプリケーションサーバー → DB（短:長マッピングを書き込み）+ キャッシュ
- **読み取りパス：**クライアント → CDN → ロードバランサー → アプリサーバー → キャッシュ（Redis）→ キャッシュミス時にDB
- **短いURLの生成：**カウンターベースのIDとbase-62エンコーディング、または分散IDジェネレーター（Snowflake）を使う
選択を声に出して述べましょう：「ここではPostgreSQLを使っています。データがリレーショナルで、書き込みに強い一貫性が必要だからです。読み取りにはRedisを前に置きます。」
ステップ4：深掘り（10〜15分）
ハイレベルの後、面接官は通常、彼らが最も気にする領域に向けます。よくある深掘りのトピック：
- データベーススキーマ設計 ——テーブル、インデックス、シャーディング戦略は？
- キャッシュ戦略 ——キャッシュアサイド vs. ライトスルー？TTL？キャッシュの無効化？
- ホットスポットの処理 ——1人の有名人ユーザーの投稿が1000万ヒットを得たら何が起きるか？
- 一貫性 vs. 可用性 ——そのトレードオフを明示的にどこで行っているか？
- データファンアウト ——ソーシャルフィードの場合、書き込みをフォロワーにどう伝播するか？
求められたら深く掘り下げましょう。面接官は「データベースの前にキャッシュを置く」から「これが退去ポリシー、これがキャッシュスタンピードの扱い方、これが私が行っているトレードオフ」に進むのを見たいのです。
ステップ5：トレードオフと代替案（5分）
意図的に除外または簡略化したものを認めて締めくくりましょう。これが良い候補者と素晴らしい候補者を分けます。
「より良い書き込みスループットを得るためにここで最終的な一貫性を選びました——しかしビジネスがすべての読み取りが最新の書き込みを反映することを要求したなら、レイテンシを加える同期レプリケーションでこれを再考する必要があるでしょう。」
これはエンジニアリングの成熟度を示します：すべてのアーキテクチャの決定は正解ではなくトレードオフであることを理解している。
よくあるシステム設計面接の質問とそれが実際にテストしているもの
| 質問 | 実際にテストしているもの |
|---|---|
| URL短縮サービスを設計する | ハッシュ化、ストレージ、高い読み取りスループット、キャッシュ |
| Twitter/Instagramフィードを設計する | ファンアウト戦略、最終的な一貫性、CDN |
| レートリミッターを設計する | トークンバケット vs. リーキーバケット、分散カウンター |
| 通知システムを設計する | 非同期処理、メッセージキュー、リトライロジック |
| 分散キャッシュを設計する | 一貫性ハッシュ、レプリケーション、退去ポリシー |
システム設計面接での最大の間違い
**コードや図に直接飛びつく。**問題が明白に思えても、毎回要件から始めましょう。
**完璧なシステムを設計する。**完璧なシステムはありません。面接官はトレードオフの推論を望みます——教科書の図ではありません。
**黙る。**思考を声に出して語りましょう。2つのアプローチを検討しているなら、そう言いましょう。「XとYの間で選んでいます——Xはより良い書き込みパフォーマンスを与えますが、Yは読み取りのスケールが容易です。100:1の読み取り比を考えると、Yにします。」
**スケールを無視する。**すべての決定はあなたの数字に接続すべきです。「これは1K QPSで機能しますが、100K QPSではシャーディングが必要です——こうアプローチします。」
今すぐ練習する
フレームワークを知ることと、面接官のプレッシャーの下でライブで適用することは、2つの非常に異なることです。