システムデザイン面接：毎回そのまま通せるフレームワーク

なぜ構造が知識に勝つのか

シニアの面接官が採点しているのは「その設計が正解か」ではありません——正解はありません。見ているのは考え方です。作る前に確認するか、トレードオフを言語化できるか、ボトルネックの場所が分かっているか。平凡な設計を落ち着いて一本道で説明しきる人は、知識は多いのに飛び回る人より高く出ます。構造そのものが信号です。

毎回そのまま通せる型

時間はおおよそこの順で使います。正確な分数より比率のほうが重要です。

• 要件の確認（約15%）。機能要件（「投稿とフォローができる」）と非機能要件（規模、レイテンシ、一貫性、可用性）を分ける。ざっくりした数字を聞く：ユーザー数、読み書き比、1件あたりのサイズ。
• 規模の見積り（約10%）。封筒の裏の計算をします：秒間リクエスト、年間ストレージ、帯域。これが設計全体を決めます——100 QPS と 100万 QPS は別の問題です。
• APIとデータモデル（約15%）。エンドポイントをいくつかと、中心となるエンティティ。以降のすべてがここに固定されます。
• 全体構成を描く（約25%）。クライアント、ロードバランサ、サービス、DB、キャッシュ、キュー。まず素朴に保ち、聞かれたところに深さを足します。
• 要所を深掘り（約25%）。面白いボトルネックを一つ選んで潜る——ホットな読み取り経路、書き込みのファンアウト、ストレージの選定。シニアの信号はここに宿ります。
• ボトルネックとトレードオフで締める（約10%）。単一障害点、ホットスポット、一貫性と可用性の取捨。何を監視するかも言う。

手を伸ばすことになる部品

ほとんどの設計は同じ数種類の部品で組み上がります。大事なのは、どれがいつ席に値するかです。

• キャッシュ——読み取りの遅延とDB負荷を削る。無効化と陳腐化を語ること。
• ロードバランサ——トラフィックを分散し、ステートレスなサービスを横に伸ばす。
• レプリカ——可用性と読み取りのスケール。代償は一貫性の遅れ。
• シャーディング——書き込みと容量を一台の外へ。ホットシャードに注意。
• キュー——生産者と消費者を切り離し、山を均し、重い処理を非同期に。
• CDN——静的でキャッシュ可能なものをユーザーの近くへ。

腕前は列挙ではありません。この課題に本当に必要なのはどれで、それぞれ何を払うのかを言えることです。

繰り返し出る六つ

これらを落ち着いて設計できれば、大半の派生は受けられます。

• 短縮URL（キー生成、リダイレクトの読み取り経路、集計）。
• フィード（書き込み時ファンアウトか読み取り時か、ランキング、大量フォロワー）。
• チャット／メッセージング（配信保証、プレゼンス、順序）。
• レートリミッタ（トークンバケット、分散カウンタ）。
• ファイル保管と共有（メタデータと実体の分離、重複排除、一貫性）。
• 配車・近傍検索（地理インデックス、マッチング）。

繰り返し出るのは、それぞれが別のトレードオフを強いるからです。

静かに減点されるところ

• 確認する前に作り始める。読み書き比を知る前にテーブル設計へ飛ぶのは経験不足の信号です。
• どこも浅い。十個の要素に三十秒ずつ触れても深さはゼロ。一つ選んで潜ること。
• 数字を出さない。見積りの裏付けがない「スケールします」は何も言っていません。
• トレードオフがない。選択には必ず代償があります。「キャッシュを入れますが、陳腐化が出るので短いTTLで抑えます」——これが全部です。
• 沈黙。面接官は口に出たものしか採点できません。

練習の仕方

上の一覧から一つ選び、四十五分でフレームワークを端から端まで、声に出して通します。できればホワイトボードか白紙のドキュメントで、メモは見ない。録画するか、相手を見つける。そのあと、時間がどこに消えたかを見返します。たいていの人は、データモデルに三十分使ってスケーリングまで到達していないことに気づきます。種類の違う課題で五回やれば、この構造は体に入ります——そしてそれが、当日あなたに考える余裕を作ってくれるものです。

この場面でアプリがどう役立つか

次に読む