設計演習

ユーザーがテキスト(paste)を投稿すると、ランダムに生成された短いリンクが返される。そのリンクにアクセスすると元のテキストを閲覧できる。ログイン不要(匿名)で使え、各pasteには「月ごとの訪問数」などの簡単なアクセス統計が見られる。一定期間で期限切れになったpasteは削除する。これを高可用に作るのが課題。URL短縮サービス(Bit.ly)も本質的に同じ構造で考えられる。

ユーザーがtweetを投稿すると、フォロワーにpush通知(やemail)が届く。ユーザーは自分のuser timeline(自分の投稿一覧)、home timeline(フォローしている人の投稿が流れてくる)を閲覧できる。キーワードでtweetを検索できる。これを高可用かつ低レイテンシで実現するのが課題。難所は『誰のhome timelineに、いつtweetを配るか(fan-out)』です。

URLのリストを起点にWebをクロールし、『単語→そのページ』の逆引き索引(reverse index)を作る。各ページのタイトルとスニペット(要約)も生成する。ユーザーが検索語を入力すると関連ページを返す。高可用で、無限ループ(同じページを延々クロールし続ける)を避けるのが課題。

ユーザーが銀行口座やクレジットカードなどの金融口座を連携すると、サービスが取引(transaction)を日次で抽出する。取引を自動でカテゴリ分け(食費・交通費など)し、月ごとのカテゴリ別支出を分析する。予算を推奨し(手動設定も可)、予算を超えたら通知する。これを高可用に作るのが課題。Pastebinと違い『書き込みが多い(write-heavy)』のが特徴です。

ソーシャルネットワークで、あるユーザーを検索して『自分から目的の人物までの最短のつながり(友達の友達の…)』を表示する。LinkedInの『〇次のつながり』のような機能。高可用が必須。最大の制約は『グラフ全体が1台のマシンに収まらない』こと。これをどう分散させ、その上で最短経路を計算するかが課題です。

検索エンジンの前段に置く、直近のクエリ結果を保存するキャッシュを設計する。検索リクエストが来たら、同じクエリの結果がキャッシュにあれば(cache hit)即返し、無ければ(cache miss)裏のサービスから取得してキャッシュに保存する。メモリは有限なので、古いエントリを賢く捨てる必要がある。高可用が必須。『LRU(最近最も使われていないものから捨てる)をどんなデータ構造で実装するか』が核心です。

Amazonで『過去1週間のカテゴリ別の人気商品ランキング(sales rank)』を算出し、ユーザーがそれを閲覧できるようにする。商品は複数カテゴリに属せるが、カテゴリ変更は不可、サブカテゴリは無し。ランキングは毎時更新(人気商品はもっと高頻度)。一般的なEC機能(購入処理など)は対象外で、『sales rankの算出』だけが課題。大量の売上ログから集計をどう効率的に作るかが核心です。

1人のユーザーしかいない状態(1台のサーバーに全部入っている)から、数千万ユーザーが使う規模まで、システムを段階的に進化させる。各段階で『何が最初に詰まるか(ボトルネック)』を見つけ、それを1つずつ解消していく。この演習は他の7問の集大成で、『スケールの考え方そのもの』を学ぶのが目的です。一気に最終形を描くのではなく、必要になってから足すのが鉄則。