システム設計面接のフレームワーク

ストーリー

あなた

45分でTwitterを設計してください

あ

高橋アーキテクトが模擬面接を始めた。

あなた

い、いきなりですか？

あ

高

高橋アーキテクト

慌てるな。大事なのは正解を出すことじゃない。構造化されたプロセスで考えを整理し、トレードオフを議論できることだ。フレームワークを使えば、どんなシステムでも同じ手順で攻略できる

4ステップフレームワーク

全体構成

// システム設計の4ステップ
const DESIGN_FRAMEWORK = {
  step1: {
    name: "要件の理解と明確化",
    duration: "5-10分",
    goal: "何を作るか、どの規模で作るかを合意する",
  },
  step2: {
    name: "ハイレベル設計",
    duration: "10-15分",
    goal: "主要コンポーネントと全体の流れを描く",
  },
  step3: {
    name: "詳細設計",
    duration: "15-20分",
    goal: "重要なコンポーネントを深掘りする",
  },
  step4: {
    name: "まとめと改善",
    duration: "5-10分",
    goal: "ボトルネックの指摘と改善案を述べる",
  },
};

Step 1: 要件の理解と明確化

// 良い質問の例（Twitter設計の場合）
const GOOD_QUESTIONS = {
  scope: [
    "ツイートの投稿と閲覧が主要機能でしょうか？",
    "リプライ、いいね、リツイートも含みますか？",
    "DM機能はスコープに含みますか？",
  ],
  scale: [
    "DAUはどの程度を想定しますか？",
    "1日あたりのツイート数は？",
    "読み書き比率はどの程度ですか？",
  ],
  constraints: [
    "タイムラインの表示速度の目標は？",
    "ツイートは全世界に配信されますか？",
    "メディア（画像・動画）のサポートは必要ですか？",
  ],
};

// 規模の概算
const TWITTER_ESTIMATES = {
  dau: 300_000_000,           // 3億DAU
  tweetsPerDay: 500_000_000,  // 5億ツイート/日
  readQPS: 300_000,           // 読み取り30万QPS
  writeQPS: 6_000,            // 書き込み6000QPS
  storagePerDay: "500GB",     // テキストのみ
  mediaStoragePerDay: "15TB", // メディア含む
};

Step 2: ハイレベル設計

クライアント
  │
  ▼
ロードバランサー
  │
  ├─→ Webサーバー群
  │     │
  │     ├─→ ツイートサービス → ツイートDB
  │     ├─→ タイムラインサービス → タイムラインキャッシュ
  │     ├─→ ユーザーサービス → ユーザーDB
  │     └─→ メディアサービス → オブジェクトストレージ
  │
  ├─→ Fan-outサービス → メッセージキュー
  │
  └─→ 通知サービス → プッシュ通知

Step 3: 詳細設計

// タイムライン生成のトレードオフ
interface TimelineApproach {
  name: string;
  description: string;
  pros: string[];
  cons: string[];
  bestFor: string;
}

const TIMELINE_APPROACHES: TimelineApproach[] = [
  {
    name: "Fan-out on Write (Push)",
    description: "ツイート投稿時にフォロワー全員のタイムラインに書き込む",
    pros: ["読み取りが超高速", "タイムライン取得はキャッシュから即座"],
    cons: ["セレブリティ問題（フォロワー数百万の場合）", "書き込みコストが大"],
    bestFor: "フォロワー数が少ない一般ユーザー",
  },
  {
    name: "Fan-out on Read (Pull)",
    description: "タイムライン取得時にフォロー先のツイートを集約する",
    pros: ["書き込みは即座", "セレブリティ問題なし"],
    cons: ["読み取りが遅い", "フォロー数が多いとJOINコスト大"],
    bestFor: "フォロワー数百万のセレブリティユーザー",
  },
  {
    name: "ハイブリッド",
    description: "一般ユーザーはPush、セレブリティはPull",
    pros: ["両方の利点を活かせる"],
    cons: ["実装が複雑"],
    bestFor: "Twitter規模のサービス（実際にこれを使用）",
  },
];

Step 4: まとめと改善

// ボトルネックと改善案を整理
const BOTTLENECKS_AND_SOLUTIONS = [
  {
    bottleneck: "ホットスポット（人気ツイートへのアクセス集中）",
    solution: "多層キャッシュ + キャッシュウォーミング",
  },
  {
    bottleneck: "単一障害点（SPOF）",
    solution: "全コンポーネントの冗長化 + 自動フェイルオーバー",
  },
  {
    bottleneck: "グローバルレイテンシ",
    solution: "マルチリージョンデプロイ + CDN",
  },
  {
    bottleneck: "データ増大によるストレージコスト",
    solution: "コールドストレージへの階層化 + データ圧縮",
  },
];

やってはいけないアンチパターン

アンチパターン	なぜダメか	代わりにどうするか
いきなり詳細設計に入る	全体像を見失う	まず要件確認とハイレベル設計
質問せずに仮定を置く	方向を間違える	明示的に質問して合意を取る
1つの解法に固執する	トレードオフを示せない	複数案を比較して理由を述べる
完璧を目指す	時間切れになる	重要部分に集中し、他は概要で済ます

まとめ

ポイント	内容
4ステップ	要件→ハイレベル→詳細→まとめ
時間配分	要件10分、ハイレベル15分、詳細20分、まとめ5分
トレードオフ	常に複数案を比較し理由を述べる
構造化	フレームワークに従えばどんな問題にも対応できる

チェックリスト

4ステップフレームワークの流れを把握した
要件明確化のための質問パターンを理解した
ハイレベル設計の描き方を把握した
トレードオフの議論方法を理解した

次のステップへ

次は「スケッチとダイアグラムの技法」を学びます。C4 Modelを使って、設計を明確に視覚化する方法を身につけましょう。

推定読了時間: 25分