システムデザイン 面接の質問

システムデザイン 面接で問われる内容

システムデザイン 面接の質問例

• bit.lyのようなURL短縮サービスを設計してください。
  良い回答が押さえる点

  • エンコード方式（Base62、ハッシュ＋衝突解決）
  • リダイレクトの仕組み（HTTP 301/302）
  • データベース設計（短縮URLと元URLのマッピング）
  • スケーラビリティ（読み取り/書き込みの分離、キャッシュ）
  • カスタムURL、有効期限、分析機能などの追加要件

  サンプル回答を見る

  URL短縮サービスは、長いURLを短い一意の識別子に変換し、アクセス時に元のURLへリダイレクトするシステムです。まず要件として、短縮URLの生成（一意性、推測困難さ）、リダイレクトの高速性、高可用性、スケーラビリティ、そして任意の有効期限や分析機能を想定します。システムアーキテクチャは、クライアントからのリクエストを受け付けるWebサーバー層、短縮ID生成ロジック、データベース、キャッシュ層で構成します。短縮ID生成には、Base62エンコード（62^7≧3.5兆通り）を用いて衝突を防ぐか、予約済みIDプールから割り当てる方式が考えられます。リダイレクト時は、データベースから元URLを取得し、HTTP 301（恒久的）または302（一時的）で返します。パフォーマンス向上のため、Redisなどのキャッシュに頻繁にアクセスされるURLを保持し、読み取り負荷を軽減します。データベースは、主キーとして短縮ID、元URL、作成日、有効期限、アクセス数などを格納します。スケーリングには、データベースのシャーディング（ID mod N）や読み取りレプリカ、CDNによる静的コンテンツ配信を活用します。注意点として、短縮URLによるセキュリティリスク（リンク先不明）や、長期的なデータ保持戦略を考慮する必要があります。フォローアップとして、カスタム短縮URLの実装方法や、分析機能のためのデータウェアハウス設計が問われる可能性があります。

• ニュースフィード（Twitter/Instagramのタイムライン）を設計してください。
  良い回答が押さえる点

  • プッシュモデル vs プルモデル（ファンアウトの考え方）
  • フィード生成のデータフロー（書き込み時・読み取り時）
  • データベース設計（投稿テーブル、ユーザー関係、フィードテーブル）
  • キャッシュ戦略（Redis、事前生成フィード）
  • スケーラビリティの課題（有名人ユーザー対策、ランキング）

  サンプル回答を見る

  ニュースフィードは、フォローしているユーザーの最新投稿を時系列順に表示する機能です。システム設計の要点は、ファンアウト（書き込み時展開 vs 読み取り時展開）の選択にあります。書き込み時展開（プッシュモデル）では、投稿時にフォロワー全員のフィードリストに書き込みます。これにより読み取りは高速ですが、多数のフォロワーを持つユーザー（有名人）の投稿時に書き込み負荷が集中します。読み取り時展開（プルモデル）では、フォロワーがフィードを取得する際にフォローしているユーザーの投稿を収集してマージします。書き込みは軽いが、読み取りに時間がかかります。多くのサービスではハイブリッド型を採用し、有名人の投稿はプル、一般ユーザーはプッシュと分けています。データベース設計では、ユーザーテーブル、フォロー関係テーブル（グラフデータベースも考慮）、投稿テーブル（投稿ID、ユーザーID、内容、タイムスタンプ、メディアURLなど）、フィードテーブル（ユーザーIDと投稿IDのリスト、事前生成済み）を用意します。パフォーマンスには、フィードをRedisなどのインメモリキャッシュに保持し、ページネーション（カーソルベース）を実装します。スケーリングでは、投稿の書き込みをリージョン別にシャーディングし、フィード生成を非同期処理（キュー利用）で行います。また、ランキングやおすすめ機能を追加する場合は機械学習モデルとデータパイプラインが必要になります。注意点として、キャッシュの一貫性と更新タイミング、ストーカー行為対策のプライバシー設定を考慮します。

• 公開API用のレートリミッターを設計してください。
  良い回答が押さえる点

  • レート制限のアルゴリズム（トークンバケット、リーキーバケット、固定ウィンドウ、スライディングウィンドウ）
  • 分散環境での一貫性（Redis、分散カウンター）
  • ルール設定（ユーザーごと、IPごと、APIキーごと）
  • レスポンスヘッダー（X-RateLimit-Limit, Remaining, Reset）
  • スケーラビリティとバックエンドへの影響

  サンプル回答を見る

  公開API用のレートリミッターは、クライアントが一定時間内に送信できるリクエスト数を制限するシステムです。要件は、正確な制限、低レイテンシ、スケーラビリティ、柔軟なルール設定です。まず、制限アルゴリズムを選択します。トークンバケットは平均レートとバーストを許容し実装が容易で、リーキーバケットは出力レートを一定に保ちます。固定ウィンドウは単純だがバースト時に問題が起きやすく、スライディングウィンドウログは高精度ですがストレージコストが高い。実装にはRedisのインクリメントと有効期限を利用したスライディングウィンドウカウンターがよく使われます。分散環境ではRedisクラスターを用い、データの一貫性のためにLuaスクリプトでアトミックな更新を行います。ルールは、APIキー、ユーザーID、IPアドレスなど粒度を設定可能にし、エンドポイントごとに異なる制限をかけます。制限超過時にはHTTP 429 Too Many Requestsを返し、Retry-Afterヘッダーを含めます。また、RateLimit関連のレスポンスヘッダー（X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset）を付与してクライアントに情報提供します。パフォーマンス向上のため、バックエンドへの負荷を軽減するためにレートリミッターをAPIゲートウェイやリバースプロキシレイヤーに組み込みます。注意点として、レート制限のオーバーヘッドが大きくならないようにRedisへのアクセスを最小限に抑え、バーストトラフィック時の挙動をテストする必要があります。フォローアップとして、分散レートリミッターの同期問題や、バックオフ戦略について問われることがあります。

• グループメッセージングと既読機能をサポートするチャットシステムを設計してください。
  良い回答が押さえる点

  • メッセージングのプロトコル（WebSocket、HTTP Long Polling）
  • メッセージの永続化と順序保証（データベース設計、タイムスタンプ＋ID）
  • グループ管理とメンバーシップ（グループテーブル、メンバーテーブル）
  • 既読機能の実装（既読テーブル、集計方法、プッシュ通知）
  • スケーラビリティ（チャットルームのシャーディング、メッセージストア）

  サンプル回答を見る

  グループメッセージングと既読機能を備えたチャットシステムでは、複数ユーザーが参加するグループでのリアルタイムメッセージ交換と、各メッセージに対する既読状況の管理が必要です。まず、通信プロトコルにはWebSocketを使用し、サーバーからクライアントへのプッシュを可能にします。メッセージはデータベースに永続化し、グループごとにメッセージテーブルを用意します。順序保証のために、メッセージにはサーバー側で採番する一意のシーケンス番号（またはタイムスタンプ＋ID）を付与します。グループ管理は、グループテーブルにグループID、作成者、作成日を格納し、メンバーテーブルでユーザーIDとグループIDの関連を管理します。既読機能は、各ユーザーが最後に読んだメッセージIDを管理するか、メッセージごとに既読ユーザーリストを保持します。後者はストレージが増大するため、グループ内のユーザー数が多い場合は、各ユーザーの最終既読メッセージIDを管理し、既読数はカウントとして別テーブルに保持する方法が効率的です。既読の更新は、ユーザーがメッセージを表示したタイミングで非同期に送信し、キャッシュ（Redis）に保持して高速に参照できるようにします。スケーリングの課題として、メッセージの書き込みと読み取りはグループIDでパーティショニングし、各パーティションを別々のデータベースシャードに配置します。また、WebSocketコネクションの管理にはコネクションサーバーを設け、クライアントはロードバランサー経由で接続します。注意点として、既読機能のリアルタイム性とデータ一貫性のトレードオフがあり、完全な正確性が不要な場合は最終整合性モデルを採用することもあります。

• サービスを1,000人から1,000万人にスケールするにはどうすればよいですか？
  良い回答が押さえる点

  • 垂直スケーリング vs 水平スケーリング
  • アーキテクチャの段階的進化（モノリス→マイクロサービス）
  • データベースのスケーリング（リードレプリカ、シャーディング、NoSQL）
  • キャッシング（CDN、アプリキャッシュ、データベースキャッシュ）
  • 非同期処理とキューイング、ロードバランシング、オートスケーリング

  サンプル回答を見る

  サービスを1,000人から1,000万人にスケールするには、段階的にアーキテクチャを改善する必要があります。初期（1,000〜10,000ユーザー）は、シングルサーバー、単一データベースで十分ですが、負荷分散のためにロードバランサーを導入します。次に（10万〜100万ユーザー）、データベースにリードレプリカを追加し、読み取り負荷を分散します。静的アセットはCDNにオフロードし、動的コンテンツにはRedisなどのキャッシュを導入します。アプリケーション層は水平スケーリング可能なステートレス設計にし、オートスケーリンググループでトラフィック変動に対応します。データベースは書き込み負荷が増えたらシャーディングを検討し、ユーザーIDや地域で分割します。非同期処理が必要なタスク（メール送信、画像処理など）はメッセージキュー（RabbitMQ、Kafka）に任せます。100万〜1,000万ユーザーでは、マイクロサービスアーキテクチャへの移行を進め、各機能を独立してスケール可能にします。また、データベースにはNoSQL（Cassandra、DynamoDB）を部分的に採用し、高スループットを実現します。監視とアラートを徹底し、ボトルネックを特定して改善を繰り返します。注意点は、早すぎる複雑化を避け、現在のユーザー数に適した段階で適切な対策を取ることです。また、データベースのシャーディングは後からの移行が困難なため、最初からシャーディングキーを考慮した設計が望ましいです。

• 高可用性を備えた分散キーバリューストアを設計してください。
  良い回答が押さえる点

  • CAP定理と一貫性モデル（強整合性 vs 結果整合性）
  • データパーティショニング（一貫性ハッシュによるシャーディング）
  • レプリケーション（リーダーベース、クォーラムベース）
  • 障害復旧（ハンドオフ、ゴシッププロトコル、ヒンテッドハンドオフ）
  • 読み取り/書き込みの最適化（キャッシュ、ベクトルクロック、マージ）

  サンプル回答を見る

  高可用性を備えた分散キーバリューストアでは、複数のノードにデータを分散し、一部のノード障害でもサービスを継続できる必要があります。設計の中心はCAP定理に基づくトレードオフです。多くのシステムでは、可用性とパーティション耐性を優先し、結果整合性を採用します（例：Dynamoスタイル）。データパーティショニングには一貫性ハッシュを用い、ノードの追加・削除時のデータ移動を最小限に抑えます。各データは複数のノードにレプリケートし（例：3ノード）、レプリカの同期にはクォーラムベースの読み書き（R+W > N）を使用して整合性を調整します。障害検出にはゴシッププロトコルを用い、ノードの生死を分散管理します。書き込み時に一部のレプリカがダウンしている場合、ヒンテッドハンドオフにより一時的に別のノードが代行書き込みし、復旧後に転送します。読み取りの整合性を高めるために、ベクトルクロックやバージョン管理を使用して競合を検出し、マージ可能にします。さらに、頻繁にアクセスされるデータにはインメモリキャッシュ（例：Redis）を併用し、読み取りレイテンシを低減します。スケーリングはノード追加による水平スケールを基本とし、自動リバランシングを実装します。注意点として、ネットワーク分割時のスプリットブレインや、データの一貫性低下によるアプリケーションへの影響を考慮し、適切な一貫性レベルを選択する必要があります。フォローアップとして、データのバックアップとリカバリ戦略、マルチデータセンター構成について問われることがあります。

準備方法

• 必ず要件と制約を明確にすることから始めましょう — いきなり解決策に飛びつかないこと。
• 反復可能なフレームワークを使用：要件 → 見積もり → API → データモデル → スケーリング → トレードオフ。
• トレードオフを明示的に述べる（例：一貫性対可用性）。通常、唯一の正解はありません。
• 会話をリードし、時間を管理 — まず広くカバーし、求められたら深掘りする。

よくある質問