system-design-interview

システム設計面接スキル

面接で通用する完全なシステム設計の回答を構成します。確認事項、要件、キャパシティの見積もり、アーキテクチャ、コンポーネント設計、トレードオフを網羅します。実際のアーキテクチャ設計の場でも同様に役立ちます。

必要な入力

提供されていない場合は、次の情報を尋ねてください。

• 設計するシステム（例：「URL短縮サービスを設計する」「通知サービスを設計する」「Twitterのフィードを設計する」）
• 目的（面接対策／実際のアーキテクチャ上の意思決定／練習）
• 目標規模（概算の数値：DAU、リクエスト数／秒、データ量など、または「一般的なウェブ規模を想定」）
• 制約や優先事項（例：一貫性より可用性を優先する、コストを最小限に抑える、読み取りの低レイテンシ）
• 利用できる時間（面接の場合のみ：30／45／60分。実際のアーキテクチャ設計の場では不要です）
• 重点項目（任意。詳しく掘り下げたい領域。例：「DB設計に重点を置く」「スケーリングにより多くの時間をかける」）

出力形式

1. 確認事項

設計を始める前に、設計に影響する質問を4～6個挙げてください。例：

• 読み取り中心ですか、それとも書き込み中心ですか？（キャッシュとDBの選択に影響します）
• グローバル展開ですか、それとも単一リージョンですか？（レイテンシ要件に影響します）
• 強い一貫性と結果整合性のどちらが必要ですか？（ストレージとレプリケーションに影響します）
• 許容可能なレイテンシの目標値はありますか？（p50／p99）
• 既存のインフラストラクチャに制約はありますか？

面接の質問に回答する場合は、前提を明示してから進めてください。

2. 機能要件

コア機能（必須）：

• [機能1]
• [機能2]
• [機能3]

対象外（今回の設計では扱わないもの）：

• [意図的に除外するものとその理由]

3. 非機能要件

要件	目標
可用性	[例：99.9%／99.99%]
レイテンシ	[例：読み取りのp95 < 100ms]
スループット	[例：ピーク時に10k書き込み／秒]
一貫性	[強い一貫性／結果整合性]
耐久性	[例：99.999% — データ損失なし]

4. キャパシティの見積もり

トラフィック：

• DAU：[X]
• 読み取り数／秒：[X]（ピーク時：[X]）
• 書き込み数／秒：[X]（ピーク時：[X]）

ストレージ：

• レコードあたりのサイズ：[X bytes]
• 1日あたりのレコード数：[X]
• 5年間のストレージ：[X GB/TB]

帯域幅：

• インバウンド：[X MB/s]
• アウトバウンド：[X MB/s]

5. ハイレベルアーキテクチャ

このシステムに即したASCII図を作成してください。実際に当てはまる場合を除き、クライアント→CDN→LB→API→キャッシュ→DBのテンプレートを安易に使わないでください。各コンポーネントには、選択した具体的なテクノロジー（例：「メッセージキュー」ではなく「Kafka」、「DB」ではなく「PostgreSQL」）を記してください。各コンポーネントの役割とそのテクノロジーを選んだ理由を、1～2文で説明してください。

6. コンポーネントの詳細

最も重要、または興味深いコンポーネントを2～3個選び、詳しく説明してください。

[コンポーネント1：例 データベース層]

• 選択：[テクノロジーと選んだ理由。例：ACID保証のためにPostgreSQL、書き込みスループットのためにCassandra]
• スキーマ設計（概要）：[主要なテーブル／コレクションとその構造]
• インデックス戦略：[インデックスを作成する対象とその理由]
• レプリケーション：[プライマリ／レプリカ／マルチプライマリとその理由]

[コンポーネント2：例 キャッシュ戦略]

• キャッシュの種類：[Redis／Memcachedとその理由]
• キャッシュ対象：[ホットデータ。例：ユーザーセッション、頻繁に読み取られるデータ]
• キャッシュ無効化：[TTL／ライトスルー／ライトビハインドとトレードオフ]
• キャッシュヒット率の目標：[例：95%]

[コンポーネント3：例 API設計]

• 主なエンドポイント：[最も重要なAPI呼び出しを3～5個列挙]
• 認証：[JWT／OAuth／APIキー]
• レート制限：[適用箇所と制限レート]

7. データフロー

最も重要な2つの経路を、最初から最後まで説明してください。

書き込み経路：[ステップ1 → ステップ2 → ステップ3...] 読み取り経路：[ステップ1 → ステップ2 → ステップ3...]

8. スケーリングのボトルネックと緩和策

ボトルネック	緩和策
[例：DBの書き込みスループット]	[例：user_idによるシャーディング、書き込みのバッチ処理]
[例：ホットキーのキャッシュミス]	[例：プロセス内ローカルキャッシュ、確率的な早期期限切れ]
[例：単一リージョンのレイテンシ]	[例：マルチリージョン展開、GeoDNSルーティング]

9. トレードオフと代替案

何を選択し、何を犠牲にしたのかを明確にしてください。

決定	理由	トレードオフ
[例：結果整合性]	[可用性の向上、レイテンシの低減]	[古いデータが読み取られる可能性がある]
[例：NoSQL ではなく SQL]	[複雑なクエリ、ACID トランザクション]	[水平方向のシャーディングが難しい]
[例：キューを介した非同期処理]	[疎結合化、耐障害性の向上]	[配信が最終的に行われるため、デバッグが難しい]

10. 今後の検討事項

本番環境で取り組む必要がありますが、この設計セッションの対象外となる項目：

• モニタリングとアラート（重要なメトリクスは何か）
• 災害復旧とバックアップ戦略
• セキュリティ（認証、保存時／転送時の暗号化、レート制限）
• 大規模運用時のコスト最適化
• 段階的なロールアウトと機能フラグの導入

品質チェック

• 明確化のための質問が設計を左右する内容になっている（一般的な埋め草ではない）
• 容量の見積もりで計算過程を示している：DAU → リクエスト数／日 → リクエスト数／秒 → レコードあたりのストレージ → 合計ストレージ。このため、数値の妥当性を確認できる
• トレードオフの表のすべての行で、トレードオフ欄が空欄ではない（トレードオフが空欄、または「なし」と記載された行がない）
• テクノロジーの選択理由を示したコンポーネントの詳細解説が少なくとも 2 つある
• トレードオフのセクションが誠実である（選択したアプローチの利点だけを述べていない）
• 重要な経路について、データフローを最初から最後まで説明している

アンチパターン

• 要件を明確化する前に解決策へ飛びつかない — まず機能要件と非機能要件を必ず明確にする
• トレードオフを議論せずに設計を提示しない — すべてのアーキテクチャ上の決定にはコストと利点があり、それらを認識する必要がある
• あいまいな容量の見積もりを使わない — 「この設計なら大規模にも対応できる」と述べるだけでなく、実際の計算（QPS、ストレージ容量、帯域幅）を示す
• デフォルトで無制限のスケールを想定して設計しない — 明示された要件に設計を合わせる
• データモデルを省略しない — エンティティの定義とデータフローがなければ、システム設計は不完全である

使用例

• 「システム設計面接の質問に答えるのを手伝ってください：[質問]」
• 「システム設計面接向けに[システム]を設計してください」
• 「[システム]を大規模に運用するには、どのようなアーキテクチャにすればよいですか？」
• 「システム設計面接を控えています — 質問は[X]です」
• 「[URL 短縮サービス／チャットシステム／通知サービス／フィード]を設計してください」