設計・実技の面接

まず要件を確かめます。例えば「1日に新しい URL が100万件、アクセスは100倍で読みが多い、短い URL は推測されにくく、リダイレクトは速く」と置きます。すると書き込みは1秒あたり十数件、読みは千件規模で、読みが多いのでキャッシュが効く構成にします。

API は POST /urls で作成、GET /{code} で 301 か 302 のリダイレクトです。アクセス数を数えたいなら、ブラウザがキャッシュしにくい 302 にします。表は code を主キーにして元の URL を持ちます。code は連番を62進数にする方法と、ランダムに作って一意制約で衝突を防ぐ方法があり、推測されにくさを優先するならランダムにします。読みは CDN と Redis でキャッシュし、アクセスの集計はキューに入れて非同期で行います。

まず規模を確かめ、例えば1日のアクティブ 1,000万人、読み取りが書き込みの 100倍、数秒の遅れは許す、と置きます。読み取りが圧倒的に多いので、投稿したときにフォロワーごとのタイムラインに投稿 ID を配っておく「書き込み時に配る」方式を基本にします。タイムラインは Redis のソート済みセットに ID だけを持ち、本文はまとめて取ってキャッシュします。

ただし、フォロワーが数百万人いる人の投稿を全員に配ると重いので、そういう人だけは配らずに、読むときに混ぜます。ページングは投稿 ID によるカーソル方式にし、配る処理はキューとワーカーで非同期にします。

在庫の二重販売を防ぐことを最優先にします。在庫は DB の条件付き更新、つまり qty > 0 のときだけ1減らす UPDATE で確保し、更新した行が0なら売り切れと返します。注文 API には冪等キーを付け、決済サービスにも同じキーを渡して二重決済を防ぎます。

集中への対策としては、待合室のキューで入場を絞る、静的なページは CDN から返す、在庫の行への更新が集中しすぎるなら在庫を複数の行に分ける、といった方法があります。決済に失敗したら在庫を戻す補償の処理を入れ、確定の通知は Outbox でジョブにします。

黙らずに、今どこで詰まっているかを言葉にします。例えば「この境界の扱いで迷っています。案は2つあり、A は単純だが重複が出る、B は正確だが少し複雑です」のように選択肢を出し、まずは単純なほうで動かしてから直すと伝えます。

API の名前を忘れたときは「調べてよいですか」と聞くか、仮の関数名で書いて後で埋めます。面接官は答えそのものより、詰まったときの進め方と対話を見ているので、ヒントをもらったら素直に取り入れます。