URL短縮サービスの設計は、システム設計面接で最も頻繁に出題される問題の一つです。bitlyやTinyURLのようなサービスを45分間で設計するという課題は、一見シンプルに見えて、実はデータベース設計、ハッシュアルゴリズムの選定、スケーリング戦略といった幅広いテーマを網羅しています。だからこそ面接官は、この問題を通じて候補者の設計力を総合的に評価できるのです。
ところで、URL短縮サービスの設計面接で失敗する人の多くは、いきなりコーディングやデータベース設計に飛びつく傾向があります。面接官が求めているのは「正解」ではなく「設計プロセス」です。要件を確認し、制約を把握し、トレードオフを分析してから設計に入るという一連の流れを、面接官とコミュニケーションを取りながら進められるかどうかが評価の核心です。
この記事では、URL短縮サービスの設計面接を最初から最後まで完全にシミュレーションしていきます。面接官との対話形式を意識しながら、要件定義、概算見積もり、API設計、データベース設計、そしてスケーリング戦略まで、面接の一連の流れを追体験してください。
要件定義フェーズ - 面接官との対話で方向性を定める
設計面接の最初の5分間は、要件を明確にする時間に充てるべきです。この段階で適切な質問ができるかどうかで、面接の方向性が決まります。面接官に「URL短縮サービスを設計してください」と言われたら、すぐに設計に入るのではなく、まずはサービスの範囲と制約を確認しましょう。
確認すべき機能要件は「長いURLを短いURLに変換する」と「短いURLにアクセスしたら元のURLにリダイレクトする」の2つが基本です。面接では「カスタムURLの作成機能は必要ですか」「URLの有効期限は設定できるべきですか」「アクセス統計の機能は求められますか」といった質問を投げかけましょう。面接官は多くの場合「まずは基本機能に絞ってください」と答えますが、これらの質問を投げかけること自体が「要件を能動的に確認できる人だ」という好印象を生みます。
非機能要件の確認も欠かせません。「1日のURL作成数はどのくらいを想定しますか」「リダイレクトのレスポンスタイムの目標はありますか」「データの保持期間は何年ですか」という質問を通じて、設計の制約を明確にします。面接では「新規URL作成は1日1億件、リダイレクトは1日100億件を想定します」のように、面接官と数字を合意してから先に進むのが理想です。
概算見積もり（Back-of-the-Envelope Estimation）
要件が明確になったら、簡単な概算見積もりを行います。この見積もりは、後のデータベース選定やスケーリング戦略の根拠になるため、面接官の前で計算プロセスを見せることが重要です。
1日1億件のURL作成は、秒間約1,200件（1億 / 86,400秒）のWriteリクエストに相当します。リダイレクトが1日100億件なら、秒間約115,000件のReadリクエストです。Read:Writeの比率は約100:1となり、読み取り性能が圧倒的に重要であることが分かります。
ストレージの見積もりも行いましょう。1つのURL レコードが約500バイト（短縮URL、元のURL、作成日時、有効期限）とすると、1日1億件で約50GB、5年間で約90TBのストレージが必要になります。面接では「この規模であれば単一のデータベースサーバーでは限界があるため、シャーディングを検討する必要があります」と、見積もりから設計判断につなげる流れを作りましょう。
短縮URLの生成アルゴリズム
URL短縮サービスの設計面接で最も技術的な議論になるのが、短縮URLの生成アルゴリズムです。面接官は、候補者がハッシュ関数の特性を理解し、衝突のリスクをどう管理するかを見ています。
短縮URLの長さから検討を始めましょう。使用する文字セットが英数字（a-z、A-Z、0-9）の62種類だとすると、7文字の短縮URLで62の7乗、約3.5兆通りの組み合わせが可能です。5年間で約180億件のURLを保存する場合、7文字あれば十分な空間があります。面接では「62進数で7文字を使えば、想定される5年分のURLを余裕を持って収容できます」と計算根拠を示しましょう。
短縮URLの生成方法として代表的なのが、MD5やSHA-256などのハッシュ関数を使うアプローチです。元のURLをハッシュ化し、その結果から最初の7文字を取り出します。ところが、この方法にはハッシュ衝突のリスクがあります。異なる元URLから同じ短縮URLが生成されてしまう可能性です。面接では「衝突が検出された場合は、元URLにソルトを追加して再ハッシュする」という対処法を提案しつつ、衝突チェックのためのデータベースクエリが追加されることも言及しましょう。
Base62エンコーディングとカウンターベースの方法
ハッシュベース以外のアプローチとして、連番IDをBase62エンコードする方法があります。データベースの自動採番機能やスノーフレークIDを利用してユニークなIDを生成し、それをBase62に変換して短縮URLとする方法です。この方法の利点は、衝突が原理的に発生しないことです。
面接で「カウンターベースの方法を採用します」と答える場合、分散環境でのID生成について掘り下げられる可能性があります。単一のカウンターサーバーはSPOF（Single Point of Failure）になるため、面接では「TwitterのSnowflakeのようにタイムスタンプ、マシンID、シーケンス番号を組み合わせた分散ID生成方式を採用します」と答えると良いでしょう。あるいは「事前にIDの範囲を各サーバーに割り当てておき、各サーバーが自律的にIDを発行する方法もあります」というZookeeperベースのレンジ割り当ても有効な選択肢です。
カウンターベースの方法にはデメリットもあります。URLが予測可能になるため、セキュリティ上の懸念があります。面接では「連番のIDではURLが推測されやすいので、セキュリティが重要な場合はIDをシャッフルするか、ハッシュベースの方法と組み合わせます」とトレードオフに触れておきましょう。
API設計とエンドポイント定義
URL短縮サービスのAPI設計は、RESTfulな原則に沿ってシンプルに設計します。面接では、エンドポイントの定義だけでなく、リクエスト・レスポンスの具体的な形式まで示すことが求められます。
URLを短縮するAPIは POST /api/v1/urls で、リクエストボディに元のURLを含めます。レスポンスには短縮URLとその有効期限を返します。面接では「べき等性を考慮して、同じ元URLに対して同じ短縮URLを返すかどうかを検討します。ストレージ効率を重視するなら同じURLを返しますが、ユーザーごとにアクセス統計を分けたい場合は毎回新しいURLを生成します」という設計判断を示しましょう。
リダイレクトのAPIは GET /{shortUrl} で、301（Permanent Redirect）または302（Temporary Redirect）のステータスコードで元のURLにリダイレクトします。面接では「301は永続的なリダイレクトで、ブラウザがキャッシュするためサーバーへのリクエスト数が減ります。ただし、アクセス統計を正確に取りたい場合は302を使い、毎回サーバーを経由させる必要があります」とHTTPステータスコードの使い分けを説明しましょう。ここでの判断は、ビジネス要件（統計の必要性）とシステム負荷（リクエスト数の削減）のトレードオフです。
レート制限とAPI認証
本番環境で運用するサービスであれば、APIの悪用を防ぐためのレート制限と認証も設計に含めるべきです。面接では、この点に触れることで実務的な視点をアピールできます。
レート制限は「1ユーザーあたり1分間に10件のURL作成」のような形で設定します。面接では「Token Bucketアルゴリズムを使い、Redisでユーザーごとのレート制限状態を管理します。レート制限を超えた場合は429（Too Many Requests）を返し、Retry-Afterヘッダーで再試行可能な時刻を通知します」と実装方法まで説明できると、完成度の高い設計を示せます。
認証については「パブリックなURL短縮機能は認証不要ですが、アクセス統計の閲覧やカスタムURL の作成にはAPIキーによる認証を要求します」と、機能ごとに認証の要否を使い分ける設計が評価されます。
データベース設計とスキーマ定義
URL短縮サービスのデータベース設計は、面接で技術的な深さを見せるポイントです。RDBMSを使うかNoSQLを使うか、スキーマをどう設計するかで、候補者のデータモデリング能力が明らかになります。
URL短縮サービスのデータモデルは比較的シンプルで、短縮URLをキーにして元のURLを取得するというアクセスパターンが中心です。Read:Writeの比率が100:1と読み取り偏重であることを考えると、キーバリュー型のアクセスに適したNoSQLデータベースが有力な候補です。面接では「DynamoDBやCassandraのようなワイドカラムストアは、キーベースの読み取りが高速で、水平スケーリングが容易なためURL短縮サービスに適しています」と選定理由を述べましょう。
テーブルスキーマは、short_url（主キー）、original_url、created_at、expires_at、user_idといったカラムで構成されます。面接では「パーティションキーにshort_urlを使用し、リダイレクト時にO(1)でデータを取得できるようにします。有効期限が切れたレコードはTTL機能で自動削除し、ストレージコストを抑えます」と、NoSQLの機能を活用した設計を提案しましょう。
RDBMSを選択する場合でも、面接では正当な理由を示せれば問題ありません。「アクセス統計の集計クエリが必要であれば、PostgreSQLのようなRDBMSの方がSQLの表現力を活かせます。読み取り性能はリードレプリカで対応し、書き込みはマスターに集約します」という回答は、トレードオフを理解したうえでの選択として評価されます。
キャッシュ層の設計
リダイレクトの秒間11万5,000件というリクエストを効率的に処理するには、データベースの手前にキャッシュ層を設置するのが不可欠です。面接でキャッシュの設計に自ら言及できると、パフォーマンスへの意識の高さをアピールできます。
Redisを使ったキャッシュは、短縮URLをキー、元のURLを値として保存します。キャッシュヒット率が80%であれば、データベースへのリクエストを8割削減でき、秒間約23,000件のDBアクセスにまで軽減できます。面接では「人気のあるURL、つまりアクセス頻度の高いURLが全体の20%であるとパレートの法則に従って仮定すると、キャッシュヒット率は80%以上を期待できます」と見積もりの根拠を示しましょう。
キャッシュの有効期限と無効化についても触れておくべきです。「短縮URLは一度作成されたら元のURLが変わることはないため、キャッシュの無効化はURLの有効期限切れ時のみです。LRU（Least Recently Used）ポリシーでメモリを管理し、TTLは24時間に設定します」と答えれば、キャッシュ設計の基本を押さえていることが伝わります。
スケーリング戦略と高可用性設計
面接の後半では、システムのスケーリングと高可用性について議論することになります。面接官は、候補者がシステムの成長に対してどのように対応するかを見ています。
水平スケーリングの基本は、ステートレスなアプリケーションサーバーを複数台配置し、ロードバランサーで負荷分散することです。面接では「アプリケーションサーバーはステートレスに設計し、セッション情報はRedisに保存します。トラフィックの増加に応じてサーバーを追加するだけでスケールできる構成です」と説明しましょう。
データベースのスケーリングについては、シャーディング戦略を提案します。短縮URLの最初の文字に基づくレンジシャーディングや、短縮URLのハッシュ値に基づくハッシュシャーディングがあります。面接では「ハッシュシャーディングを採用し、short_urlのハッシュ値に基づいてシャードを決定します。これにより、データが各シャードに均等に分散され、特定のシャードに負荷が集中することを防ぎます」という回答が期待されます。
高可用性の設計では、各コンポーネントの冗長化を説明しましょう。「アプリケーションサーバーは複数台配置してロードバランサーで振り分け、データベースはマスター-レプリカ構成にし、Redisもレプリケーションを設定します。いずれかのコンポーネントが障害を起こしても、自動的にフェイルオーバーしてサービスを継続できる構成です」と述べれば、可用性への配慮が伝わります。
リダイレクト処理の最適化
リダイレクト処理はURL短縮サービスの中核であり、レイテンシを極限まで低くする必要があります。面接でこの部分の最適化に言及すると、パフォーマンスに対する深い理解を示せます。
リダイレクト処理のフローは、キャッシュの確認、キャッシュミスの場合のDB問い合わせ、301/302レスポンスの返却です。面接では「キャッシュヒット時のレスポンスタイムは1ms以下を目標にします。Redisへのネットワークラウンドトリップが主な遅延要因なので、アプリケーションサーバーとRedisを同じデータセンター内に配置します」という具体的な最適化方針を示しましょう。
CDNの活用も議論に値するポイントです。「人気の高い短縮URLについては、CDNでリダイレクトレスポンスをキャッシュすることで、アプリケーションサーバーへのリクエストをさらに削減できます。ただし、301レスポンスはブラウザにキャッシュされるため、CDNキャッシュとブラウザキャッシュの相互作用に注意が必要です」と述べることで、キャッシュ戦略の多層的な理解を示せます。
まとめ
URL短縮サービスの設計面接は、要件定義からスケーリング戦略まで、システム設計の全工程を凝縮した問題です。シンプルなサービスに見えて、ハッシュアルゴリズムの選定、データベースのスケーリング、キャッシュ戦略、高可用性設計と、議論すべきテーマは多岐にわたります。面接官が見ているのは最終的な設計図ではなく、そこに至るまでの思考プロセスとコミュニケーション能力です。
面接で成功するための鍵は、各設計判断に明確な根拠を持つことです。「なぜNoSQLを選んだのか」「なぜBase62エンコーディングを選んだのか」「なぜキャッシュのTTLを24時間に設定したのか」という問いに対して、ユースケースの特性や概算見積もりの結果に基づいた回答ができることが、高評価への近道です。
この記事のシミュレーションを何度も読み返し、自分の言葉で説明できるように練習してみてください。実際の面接では、ここに書かれた内容をそのまま述べるのではなく、面接官の反応に合わせて深掘りする箇所を変えていく柔軟さが大切です。この柔軟さこそが、面接官に「一緒に働きたい」と思わせる最大の武器になるでしょう。