チャットシステムの設計面接は、リアルタイム通信という独特の技術課題を含んでおり、通常のCRUDアプリケーションとは根本的に異なるアプローチが求められます。LINEやSlackのようなチャットアプリを設計してくださいと言われたとき、何から手をつければ良いか分からないと感じる人は多いのではないでしょうか。HTTPのリクエスト-レスポンスモデルに慣れているエンジニアにとって、双方向通信の設計は未知の領域に感じられることがあります。
実は、チャットシステム設計面接で面接官が見ているのは、WebSocketの仕組みを暗唱できるかどうかではありません。重要なのは、リアルタイムメッセージ配送、オンライン状態管理、メッセージの永続化、そしてグループチャットのスケーリングといった複合的な課題に対して、体系的にアプローチできるかどうかです。チャットシステムは単一の技術的課題ではなく、複数のサブシステムが協調して動くことで成り立つ複雑なシステムなのです。
この記事では、チャットシステム設計面接のウォークスルーを最初から最後まで再現します。面接官との対話を想定しながら、要件定義から通信プロトコルの選定、メッセージ配送の設計、そしてスケーリング戦略まで、評価ポイントを押さえた回答方法をお伝えします。
要件の明確化とシステムの範囲定義
チャットシステムの設計面接では、最初にシステムの範囲を明確にすることが極めて重要です。「チャットシステムを設計してください」という問題は非常に広範で、1対1のチャットなのかグループチャットなのか、テキストだけなのかファイル共有も含むのかで、設計は大きく変わります。
面接官に確認すべき項目として、まずチャットの形式があります。「1対1チャットとグループチャットの両方をサポートしますか」「グループの最大人数は何人ですか」という質問は必ず投げかけましょう。面接官が「1対1チャットを中心に、最大100人のグループチャットもサポートしてください」と答えた場合、グループチャットのブロードキャスト設計が重要なテーマになります。
メッセージの種類と永続性も確認が必要です。「テキストメッセージのみですか、それとも画像や動画の送信もサポートしますか」「メッセージの履歴は永久保存ですか、それとも一定期間後に削除しますか」という質問を通じて、ストレージ設計の方向性が見えてきます。面接では「まずはテキストメッセージの1対1チャットとグループチャットに焦点を絞り、基本アーキテクチャを固めてからファイル共有の拡張について議論します」と、スコープを区切る姿勢を見せると面接官に安心感を与えられます。
概算見積もりとボトルネックの予測
要件が固まったら、トラフィックの見積もりを行いましょう。DAU（Daily Active Users）が5,000万人、1ユーザーあたり1日平均40メッセージを送信すると仮定すると、1日のメッセージ総数は20億件です。秒間で約23,000件のメッセージ送信が発生する計算になります。
ストレージの見積もりも重要です。1メッセージが平均100バイト（メタデータ含む）だとすると、1日20億件で約200GBのストレージが必要です。5年間の保持で約365TBになります。面接では「この規模のデータを効率的に管理するには、時系列データに適したデータベースや、データのパーティショニングが不可欠です」と、見積もりから設計の方向性を導き出しましょう。
チャットシステムで注目すべきはコネクション数です。5,000万DAUのうち、同時接続のピークが全体の10%（500万ユーザー）だとすると、500万のWebSocket接続を維持する必要があります。面接では「1台のサーバーが6万5千接続を処理できるとすると、最低でも約80台のWebSocketサーバーが必要です。実際には余裕を見て100台以上を用意し、ロードバランサーで分散します」と具体的な数字を示しましょう。
通信プロトコルの選定
チャットシステムの設計面接で必ず議論になるのが、通信プロトコルの選定です。HTTPのリクエスト-レスポンスモデルでは、サーバーからクライアントへのリアルタイムなメッセージ配送ができないため、双方向通信を実現する仕組みが必要になります。
WebSocketは、現代のチャットシステムで最も広く採用されているプロトコルです。HTTPでハンドシェイクを行った後、TCPコネクションをアップグレードして全二重通信を確立します。一度接続が確立されれば、サーバーとクライアントの双方が自由にデータを送信でき、新しいメッセージの即時配信が可能になります。面接では「WebSocketを使うことで、サーバーはメッセージを受信した瞬間に宛先のクライアントにプッシュ配信できます。ポーリングのように無駄なリクエストが発生しないため、サーバーリソースを効率的に利用できます」と説明しましょう。
ところで、WebSocket以外の選択肢にも触れておくと、面接官に幅広い知識をアピールできます。Server-Sent Events（SSE）はサーバーからクライアントへの一方向通信に使えますが、クライアントからサーバーへの通信にはHTTPを別途使う必要があるため、チャットシステムにはやや不向きです。Long Pollingは、クライアントがHTTPリクエストを送信し、サーバーが新しいメッセージが来るまでレスポンスを保留する方法です。WebSocketが使えない環境でのフォールバックとして言及するのは良いですが、メインの通信方式としては非効率です。
メッセージ送信と受信のフロー
面接では、メッセージの送信から受信までの具体的なフローを説明することが求められます。このフローを明確に描けるかどうかで、候補者のシステム設計力が判断されます。
ユーザーAがユーザーBにメッセージを送信する場合のフローは次のようになります。AのクライアントがWebSocket経由でメッセージをチャットサーバーに送信し、チャットサーバーはメッセージにIDとタイムスタンプを付与してメッセージストアに永続化します。永続化が完了したら、チャットサーバーはBが接続しているWebSocketサーバーを特定し、そのサーバー経由でBにメッセージを配信します。
面接で掘り下げられやすいポイントが「受信者がオフラインの場合はどうするか」という問題です。「Bがオフラインの場合、メッセージはメッセージストアに保存されたまま配信を保留します。Bが再度オンラインになったとき、未読メッセージの一覧を取得するAPIを呼び出し、オフライン中に受信したメッセージを一括取得します」という設計を説明しましょう。プッシュ通知の仕組みも組み合わせて「オフラインのユーザーにはFCMやAPNsを通じてプッシュ通知を送り、アプリを開くように促します」と付け加えると、モバイル対応の観点も示せます。
メッセージの永続化とデータモデル
チャットメッセージの永続化は、システム設計面接で技術的な深さを見せるポイントです。チャットメッセージのアクセスパターンは通常のRDBMSが得意とするパターンとは異なるため、データベースの選定に面接官は特に注目します。
チャットメッセージの主なアクセスパターンは、特定の会話の最新N件のメッセージを時系列順に取得するというものです。ユーザーがチャットルームを開いたとき、最新の20件を表示し、スクロールアップするたびに過去のメッセージを追加読み込みするという使い方が一般的です。このアクセスパターンは、時系列データの管理に適したデータベースが最適です。
面接では「HBaseやCassandraのようなワイドカラムストアを採用します。パーティションキーをchat_room_id、クラスタリングキーをタイムスタンプにすることで、特定の会話のメッセージを時系列順に効率的に取得できます」と具体的なスキーマを提案しましょう。この設計であれば、1つのチャットルームのメッセージが物理的に隣接して格納されるため、シーケンシャルリードで高速に読み取れます。
メッセージIDの設計
チャットメッセージのIDは、単なるユニーク識別子としてだけでなく、メッセージの順序を決定する役割も果たします。面接ではこのID設計について掘り下げられることがあります。
「データベースの自動採番を使えばいいのでは」と思うかもしれませんが、分散データベースでは自動採番のグローバルな順序保証が難しいという問題があります。面接では「Snowflake IDを使ってメッセージIDを生成します。タイムスタンプベースのIDなので、ID自体がおおよその時系列順序を表し、ソートの基準としても利用できます」と答えると良いでしょう。
もう一つの選択肢として、同一チャットルーム内でのみ順序を保証するローカルシーケンス番号があります。「グローバルな順序は不要で、チャットルーム内の順序さえ保証されれば十分です。各チャットルームにシーケンスカウンターを持たせ、新しいメッセージごとにインクリメントします」という設計も面接では有効です。グローバル順序を放棄することでスケーラビリティを向上させるという、トレードオフの判断を明確に説明しましょう。
グループチャットのメッセージ配送
グループチャットの設計は、1対1チャットの設計をそのまま拡張しただけでは対応できない複雑さがあります。面接官がグループチャットの設計を問うのは、候補者がスケーリングの課題をどう解決するかを見たいからです。
100人のグループチャットで1つのメッセージが送信された場合、そのメッセージを99人のメンバー全員に配信する必要があります。各メンバーが異なるWebSocketサーバーに接続している場合、メッセージを各サーバーにルーティングする仕組みが必要です。面接では「メッセージキュー（Kafkaなど）を使って、各ユーザーのメッセージキューにメッセージを配信します。各WebSocketサーバーは、自分が担当するユーザーのキューからメッセージを消費して配信します」というファンアウト方式を説明しましょう。
ここで面接官から「ユーザーごとにキューを持つとキューの数が膨大になりませんか」という突っ込みが来る可能性があります。「DAU 5,000万人分のキューを持つのは現実的ではないため、オンラインユーザーのみキューを作成し、オフラインになったタイミングで破棄します。オフラインユーザーへのメッセージはメッセージストアから取得できるため、キューに保持する必要はありません」と答えることで、メモリ効率を考慮した設計を示せます。
オンライン状態（プレゼンス）管理
チャットシステムのもう一つの重要な機能が、ユーザーのオンライン・オフライン状態の管理です。面接官はこのプレゼンス管理の設計を通じて、候補者が大規模な状態管理の課題をどう解決するかを見ています。
シンプルな実装としては、ユーザーがWebSocket接続を確立したときにオンライン、接続が切れたときにオフラインとする方法があります。ところが、ネットワークの一時的な不安定さで接続が瞬間的に切れてもすぐにオフラインと判定するのは望ましくありません。面接では「ハートビートメカニズムを導入します。クライアントが30秒ごとにハートビートを送信し、サーバーは60秒間ハートビートを受信しなかった場合にオフラインと判定します。この遅延により、一時的なネットワーク障害でステータスがちらつくことを防ぎます」と説明しましょう。
オンライン状態の更新をすべてのフレンドにリアルタイムで通知する設計は、フレンド数が多いユーザーにとって大量の通知を生成するため、スケーリングの課題があります。面接では「フレンド数が少ない場合はリアルタイムに通知しますが、大規模なグループやフレンド数が多いユーザーについては、チャットルームを開いたときにオンデマンドで状態を取得する方式にします」というアプローチの使い分けを提案できると、実用的な設計力を示せます。
スケーリングと高可用性の設計
チャットシステムのスケーリングは、通常のWebアプリケーションとは異なる課題があります。WebSocket接続はステートフルであるため、ロードバランサーによる単純な負荷分散だけでは不十分です。面接では、この「ステートフルな接続」という課題にどう対処するかが大きな評価ポイントになります。
WebSocketサーバーのスケーリングには、接続管理のためのサービスディスカバリが必要です。面接では「ユーザーとWebSocketサーバーのマッピングをRedisやZookeeperで管理します。ユーザーAがメッセージをユーザーBに送信する際、まずBが接続しているWebSocketサーバーを特定し、そのサーバーにメッセージをルーティングします」と説明しましょう。
サーバーの障害時には、そのサーバーに接続していたすべてのクライアントが再接続する必要があります。面接では「クライアント側にリコネクションロジックを実装し、接続が切れた場合はエクスポネンシャルバックオフで再接続を試みます。再接続時には、切断中に受信できなかったメッセージを同期するため、最後に受信したメッセージIDをサーバーに送信し、それ以降のメッセージを取得します」という障害復旧の設計まで説明できると、完成度の高い回答になります。
メッセージ配送のべき等性と順序保証
チャットシステムでメッセージが重複して表示されたり、順序が入れ替わったりすると、ユーザー体験を大きく損ないます。面接では、メッセージの重複排除と順序保証の仕組みを説明できることが重要です。
重複排除は、メッセージIDの一意性に依存します。「クライアントがメッセージ送信時にクライアント側でUUIDを生成し、サーバー側でこのIDの重複をチェックします。ネットワークの問題で同じメッセージが複数回送信された場合でも、同じIDのメッセージは一度しか保存・配信されません」という設計を説明しましょう。
順序保証については「同一チャットルーム内のメッセージは、サーバーで付与するシーケンス番号で順序を管理します。クライアントは受信したメッセージをシーケンス番号に基づいてソートして表示するため、ネットワーク遅延で受信順序が前後してもUIでは正しい順序で表示されます」と答えましょう。この設計により、ネットワークの不確実性がユーザー体験に影響しないことを保証できます。
まとめ
チャットシステム設計面接は、リアルタイム通信、メッセージ永続化、グループ配送、プレゼンス管理、そしてスケーリングという多面的な課題を含むテーマです。面接官が評価しているのは、これらの課題を体系的に整理し、優先順位をつけながら設計を進められるかどうかという全体を俯瞰する力です。
面接で成功するためのポイントは、各コンポーネントの設計判断に根拠を持つことです。「WebSocketを選んだ理由」「メッセージストアにCassandraを選んだ理由」「オンライン状態にハートビートを使う理由」など、すべての設計判断に「なぜ」を説明できるように準備しておきましょう。特にトレードオフの説明は、面接官に技術的な深さを印象づける最も効果的な手段です。
チャットシステムは日常的に使うアプリケーションだからこそ、ユーザーとしての直感とエンジニアとしての技術的判断を結びつけて語れることが強みになります。この記事のウォークスルーを参考に、自分なりの設計ストーリーを組み立てて、面接に自信を持って臨んでください。