システム設計面接2025完全攻略：FAANGが聞く30問とAI時代の新パターン

質問例：
- 「ユーザーができる核心的なアクション3つは何ですか？」
- 「読み込みと書き込みの比率はどのくらいですか？」
- 「データはどのくらい保持する必要がありますか？」

確認事項：
- 可用性：99.9% vs 99.99%（年間ダウンタイム8.7時間 vs 52分）
- レイテンシ：p99 < 200ms等の具体的な数値
- 一貫性：強い一貫性 vs 結果整合性
- 規模：DAU、同時接続者数、データサイズ

例：チャットシステムの規模推定

- DAU：5000万人
- 1日の平均メッセージ数：40件/ユーザー
- 総メッセージ：5000万 x 40 = 20億件/日
- QPS：20億 / 86,400 = 約23,000 QPS
- ピークQPS：平均の3倍 = 約70,000 QPS
- メッセージサイズ：平均100バイト
- 日次ストレージ：20億 x 100B = 200GB/日
- 年間ストレージ：200GB x 365 = 73TB/年

典型的なハイレベルアーキテクチャ：

Client --> Load Balancer --> API Gateway
                               |
                    +----------+----------+
                    |          |          |
                Service A  Service B  Service C
                    |          |          |
                 DB (SQL)  Cache     Message Queue
                              |          |
                           DB (NoSQL)  Worker

ディープダイブ領域：

1. データベーススキーマ設計
   - テーブル構造、インデックス、パーティショニング戦略

2. API設計
   - エンドポイント、リクエスト/レスポンス形式、エラー処理

3. 核心アルゴリズム
   - ニュースフィード：Fan-out on write vs Fan-out on read
   - 検索：転置インデックス構造
   - 推薦：協調フィルタリング vs コンテンツベースフィルタリング

チェックリスト：
- 単一障害点（SPOF）の識別と除去
- データ複製戦略（リーダー・フォロワー、マルチリーダー）
- 障害検知と自動復旧（ヘルスチェック、サーキットブレーカー）
- モニタリング指標（レイテンシ、エラーレート、スループット）
- アラートシステム（PagerDuty、Slack連携）

垂直スケーリング：
  サーバー1台 (4 CPU, 16GB RAM) --> サーバー1台 (32 CPU, 128GB RAM)

水平スケーリング：
  サーバー1台 --> サーバー10台 (各4 CPU, 16GB RAM) + Load Balancer

L7ロードバランサーのルーティング例：

/api/users/*  --> User Service Cluster
/api/orders/* --> Order Service Cluster
/api/search/* --> Search Service Cluster
/static/*     --> CDN Origin

読み込みリクエストフロー：
1. キャッシュでデータを検索
2. キャッシュヒット --> データを返す
3. キャッシュミス --> DBから取得 --> キャッシュに保存 --> 返す

利点：必要なデータのみキャッシュ、キャッシュ障害時はDBにフォールバック
欠点：初回リクエストは常に遅い、キャッシュとDBの不整合の可能性

書き込みリクエストフロー：
1. キャッシュにデータを書き込み
2. キャッシュが同期的にDBに記録
3. 完了レスポンス

利点：キャッシュとDBが常に一致
欠点：書き込みレイテンシの増加、不要なデータもキャッシュ

書き込みリクエストフロー：
1. キャッシュにデータを書き込み
2. 即座に完了レスポンス
3. 非同期でバッチ処理してDBに記録

利点：書き込み性能の最大化
欠点：キャッシュ障害時のデータ損失リスク

1. 範囲ベースシャーディング（Range-based）
   - user_id 1~100万 --> Shard 1
   - user_id 100万~200万 --> Shard 2
   - 利点：範囲クエリが効率的
   - 欠点：ホットスポットの発生リスク

2. ハッシュベースシャーディング（Hash-based）
   - hash(user_id) % N --> Shard番号
   - 利点：均等分配
   - 欠点：範囲クエリが非効率、リバランシングが複雑

3. ディレクトリベースシャーディング
   - ルックアップテーブルで管理
   - 利点：柔軟なマッピング
   - 欠点：ルックアップテーブルが単一障害点

Kafkaアーキテクチャ：

Producer --> Topic (Partition 0) --> Consumer Group A
                                 --> Consumer Group B
         --> Topic (Partition 1) --> Consumer Group A
                                 --> Consumer Group B
         --> Topic (Partition 2) --> Consumer Group A
                                 --> Consumer Group B

- パーティション：並列処理単位
- Consumer Group：独立した消費
- Offset：消費位置の追跡

CDN動作原理：

ユーザー（日本） --> 日本エッジサーバー（キャッシュヒット） --> 即座にレスポンス
                                     （キャッシュミス） --> オリジンサーバー（米国） --> キャッシュ保存 --> レスポンス

Pull CDN：初回リクエスト時にオリジンから取得してキャッシュ（CloudFront、Cloudflare）
Push CDN：事前にコンテンツを配布（大容量静的ファイルに適合）

REST例：
GET /api/v1/users/123
GET /api/v1/users/123/orders?page=1&limit=10

gRPC例：
service UserService {
  rpc GetUser(GetUserRequest) returns (User);
  rpc ListOrders(ListOrdersRequest) returns (stream Order);
}

GraphQL例：
query {
  user(id: "123") {
    name
    orders(first: 10) {
      id
      total
    }
  }
}

基本ハッシングの問題：
  hash(key) % N = サーバー番号
  Nが変更されるとほぼ全てのキーが再マッピングされる

コンシステントハッシング：
  - ハッシュ空間を円形（0 ~ 2^32-1）に構成
  - サーバーとキーの両方を円上に配置
  - キーは時計回りに最も近いサーバーに割り当て
  - サーバーの追加/削除時は隣接区間のみ影響

仮想ノード（Virtual Nodes）：
  - 各物理サーバーを複数の仮想ノードにマッピング
  - 負荷をより均等に分配
  - サーバー性能の差に応じて仮想ノード数を調整可能

動作原理：
1. 固定サイズのバケットに一定速度でトークンを追加
2. リクエストごとにトークンを1つ消費
3. トークンがなければリクエスト拒否（HTTP 429）

パラメータ：
- バケットサイズ：100（瞬間最大リクエスト）
- リフィル速度：10個/秒（平均処理速度）

動作原理：
1. 各リクエストのタイムスタンプをソートされたログに記録
2. 現在時刻基準でウィンドウ（例：1分）外の記録を削除
3. ウィンドウ内のリクエスト数が上限を超えたら拒否

利点：正確なウィンドウ境界処理
欠点：メモリ使用量が高い（全タイムスタンプを保存）

方法1：集中型（Redisベース）
  - 全サーバーがRedisのカウンターを共有
  - 正確だがRedisがボトルネック/障害点

方法2：ローカル + 同期
  - 各サーバーでローカルカウンティング
  - 定期的に中央と同期
  - 高速だが若干の超過を許容

核心設計ポイント：
1. 短縮URL生成：Base62エンコーディング vs ハッシュ（MD5/SHA256の切り詰め）
2. 衝突処理：DBユニーク制約 + リトライ vs カウンターベース
3. リダイレクション：301（永久） vs 302（一時）の選択根拠
4. キャッシュ：頻繁にアクセスされるURLをRedisにキャッシュ（80/20ルール）
5. アナリティクス：クリック数、地域、デバイス追跡

Fan-out on Write（Pushモデル）：
- 投稿時に全フォロワーのフィードに即座に記録
- 利点：読み込みが速い
- 欠点：フォロワーが多いユーザー（セレブ）の書き込みコストが高い

Fan-out on Read（Pullモデル）：
- フィード閲覧時にフォロワーリストからリアルタイム集計
- 利点：書き込みコストが低い
- 欠点：読み込みが遅い

ハイブリッド（実践的な解答）：
- 一般ユーザー：Pushモデル
- セレブ（フォロワー100万人以上）：Pullモデル
- 両方を合わせて最終フィードを生成

アーキテクチャ：
1. 接続管理：WebSocketサーバー + 接続状態ストア
2. メッセージ配信：1対1は直接配信、グループはFan-out
3. オフライン処理：メッセージキューに保存し、再接続時に配信
4. 既読確認：別サービスとして分離
5. メッセージストレージ：時系列ソートに最適化されたDB選択
   - HBase/Cassandra（ワイドカラムストア）

推薦システム全体パイプライン：

データ収集 --> Feature Store --> モデル訓練 --> モデルレジストリ
     |                              |                |
ユーザー行動ログ              オフラインバッチ         A/Bテスト
クリック、購入、視聴         日次/週次更新      チャンピオン/チャレンジャー
     |                              |                |
     v                              v                v
リアルタイム特徴計算 --> 候補生成  -->  ランキング  -->  リランキング  -->  表示
                    (Retrieval)    (Scoring)     (Re-ranking)

核心コンポーネント：
1. Feature Store：オフライン（バッチ）+ オンライン（リアルタイム）特徴管理
2. Candidate Generation：ANN（近似最近傍）で候補1000件を選別
3. Ranking Model：候補を精密モデルでスコアリング（ディープラーニング）
4. Re-ranking：ビジネスルール、多様性、新鮮度を適用

LLMサービングアーキテクチャ：

リクエスト --> API Gateway --> リクエストルーター --> GPUクラスター
                                  |                    |
                             トークンリミッター   モデルインスタンス（vLLM）
                             キュー管理者              |
                                  |              KV Cache管理
                             レスポンスストリーミング <--- |
                                  |
                             コスト追跡

核心最適化技法：
1. KV Cache：前のトークンのKey/Valueをキャッシュして重複計算を防止
2. Continuous Batching：動的にリクエストをバッチ処理
3. PagedAttention：メモリをページ単位で管理（vLLM）
4. 量子化：FP16 --> INT8/INT4でモデルサイズを縮小
5. Speculative Decoding：小さいモデルで草案生成後、大きいモデルで検証

GPUオートスケーリングの考慮事項：
- GPUインスタンス起動時間：3-10分（CPUに比べて非常に遅い）
- 予測ベーススケーリング：時間帯別トラフィックパターンを事前学習
- キュー深度ベース：待機中のリクエスト数でスケーリングトリガー
- コスト最適化：スポットインスタンス活用 + オンデマンドフォールバック

RAGパイプラインアーキテクチャ：

文書収集 --> チャンキング --> エンベディング生成 --> ベクトルDB保存
                                                      |
ユーザー質問 --> クエリエンベディング --> 類似度検索 --> 上位K件の文書検索
                                                          |
                                プロンプト構成 <-----------+
                                     |
                                LLM生成 --> レスポンス + 出典引用

核心設計決定：
1. チャンキング戦略：固定サイズ vs 意味ベース（段落/セクション）
2. エンベディングモデル：OpenAI Ada-002、Cohere Embed、オープンソースモデル
3. ベクトルDB：Pinecone（マネージド）、Milvus（セルフホスティング）、pgvector
4. 検索方式：純粋なベクトル検索 vs ハイブリッド（ベクトル + キーワード）
5. リランキング：Cross-encoderで検索結果を精密に再順序付け

リアルタイムMLパイプライン：

イベントソース --> Kafka --> Stream Processor (Flink) --> Feature計算
                                                           |
                                                      Feature Store
                                                           |
APIリクエスト --> Model Server --> 推論結果 --> ビジネスロジック
                    |
               Model Registry (MLflow)

ユースケース：
- 不正取引検知：決済イベント --> リアルタイム特徴 --> 不正スコア
- リアルタイム推薦：ユーザー行動 --> リアルタイムエンベディング更新 --> 推薦更新
- ダイナミックプライシング：需給シグナル --> 価格モデル --> 価格調整

AI安全装置アーキテクチャ：

ユーザー入力 --> 入力フィルタ --> LLM --> 出力フィルタ --> ユーザーレスポンス
                   |                        |
              コンテンツ分類器          ハルシネーション検知器
              プロンプトインジェクション検知   事実検証器
              PII検知/マスキング            毒性フィルタ
                   |                        |
              ブロック or 警告          修正 or ブロック

設計ポイント：
1. 多層防御：入力/処理/出力の各段階にフィルタ
2. 非同期監査：全会話ログを非同期で分析
3. 適応型ルール：新しい攻撃パターンに対する迅速なルール更新
4. ヒューマン・イン・ザ・ループ：自動化が不確実なケースに人間レビュー
5. レイテンシバジェット：安全装置が追加するレイテンシの最小化（目標：50ms以下）

操作                           時間
---------------------------   ----------
L1キャッシュ参照                1 ns
L2キャッシュ参照                4 ns
メインメモリ（RAM）参照          100 ns
SSDランダム読み取り              100 us（マイクロ秒）
HDDシーク                      10 ms
同一データセンターネットワークRTT  0.5 ms
大陸間ネットワークRTT            150 ms

記憶のコツ：
- L1はRAMより100倍速い
- SSDはRAMより1000倍遅い
- HDDはSSDより100倍遅い
- ネットワークはローカルI/Oより常に遅い

QPS（Queries Per Second）：
  QPS = DAU * 平均リクエスト数 / 86,400
  ピークQPS = 平均QPS * 2~5（サービス特性による）

ストレージ：
  日次データ = 日次新規レコード * 平均レコードサイズ
  年間データ = 日次データ * 365
  総ストレージ = 年間データ * 保持期間（年） * レプリケーション係数（通常3）

帯域幅：
  インバウンド = 書き込みQPS * 平均リクエストサイズ
  アウトバウンド = 読み込みQPS * 平均レスポンスサイズ

主要サービスのおおよその規模：

サービス       DAU          QPS（平均）    ストレージ
------        --------     ---------    --------
Twitter       5億          30万         毎日数TB
Instagram     20億         100万        毎日数十TB
YouTube       20億+        50万+        毎分500時間アップロード
WhatsApp      20億+        数百万       毎日100億メッセージ
Google検索    85億クエリ/日  10万+       数百PBインデックス

2の冪乗（頻繁に使用）：
- 2^10 = 1,024（約1千）
- 2^20 = 1,048,576（約100万）
- 2^30 = 1,073,741,824（約10億）
- 2^40 = 約1兆（1TB）

週次学習計画：

1-2週目：基礎概念（DDIA核心チャプター）
  - スケーラビリティ、可用性、一貫性の原理
  - データベース、キャッシュ、メッセージキューの基礎

3-4週目：フレームワーク練習（Alex Xu Vol.1）
  - 45分フレームワークの体得
  - 簡単な問題5問を解く

5-8週目：実践問題演習（Alex Xu Vol.2 + Codemia）
  - 中級問題10問
  - 週3-4問、タイマー使用

9-10週目：高度なトピック + AI/MLシステム
  - 分散システムの深掘り
  - LLMサービング、推薦システム

11-12週目：模擬面接
  - 同僚と模擬面接3-5回
  - 弱点補強の集中学習

良い明確化質問の例：
- 「ファイルのアップロードとダウンロード、どちらに注力すべきですか？」
- 「ユーザー規模はどの程度ですか？1億人レベルですか？」
- 「リアルタイム共同編集もスコープに含まれますか？」
- 「モバイルとウェブの両方をサポートする必要がありますか？」

トレードオフ分析例：

質問：「メッセージストレージとしてCassandraとMySQLのどちらを選びますか？」

良い回答の構造：
1. 要件確認：「チャットメッセージは書き込みが多く（Write-heavy）、
   時系列クエリが大半で、強い一貫性より可用性が重要です。」

2. オプション比較：
   - MySQL：ACID保証、JOIN可能、しかし水平スケーリングが難しく
     シャーディングの複雑性が高い
   - Cassandra：水平スケーリング容易、書き込み最適化、
     時系列データに適合、しかしJOIN不可

3. 結論：「我々の要件では書き込み性能と水平スケーラビリティが
   核心なのでCassandraを選択します。ユーザープロフィールのような
   リレーションが複雑なデータは別途MySQLに保存します。」

スケーリングシナリオ対応フレームワーク：

現在の規模（100万DAU）：
- 単一DB、読み取りレプリカ2台、キャッシュサーバー1台

10倍成長（1000万DAU）：
- DBシャーディング導入（ユーザーIDベース）
- キャッシュクラスター拡張（Redis Cluster）
- CDN導入（静的アセット）
- 読み取り/書き込み分離

100倍成長（1億DAU）：
- マルチリージョンデプロイ
- マイクロサービス分離
- イベント駆動アーキテクチャへの移行
- 専用検索エンジン（Elasticsearch）

効果的なコミュニケーション技法：

1. ホワイトボードの活用
   - 常に図と一緒に説明
   - データフローを矢印で表示
   - コンポーネント名を明確に表記

2. チェックポイントの設定
   - 「ここまで問題なければ次に進みます」
   - 「この部分をもっと深く掘り下げましょうか？」

3. 思考プロセスの共有
   - 黙って考えるのではなく、思考プロセスを声に出して共有
   - 「2つのオプションがあります。Aは... Bは...」