中
Mint.com(家計管理)を設計せよ
課題
ユーザーが銀行口座やクレジットカードなどの金融口座を連携すると、サービスが取引(transaction)を日次で抽出する。取引を自動でカテゴリ分け(食費・交通費など)し、月ごとのカテゴリ別支出を分析する。予算を推奨し(手動設定も可)、予算を超えたら通知する。これを高可用に作るのが課題。Pastebinと違い『書き込みが多い(write-heavy)』のが特徴です。
制約・前提
- ユーザーは10M(1000万)人
- 1ユーザー10カテゴリ → 100M budget items
- 金融口座は30M(3000万)件
- 取引は5B(50億)/月
- 読み取りは500M req/月
- write:read = 10:1 (書き込みが多い = write-heavy)
- 1取引あたり50 bytes
- 平均200 read req/s(ピークはもっと高い)、高可用が必須
主要数値
概算（back-of-the-envelope）の出発点。
| write:read比 | 10:1 (write-heavy) |
|---|---|
| 取引書き込み | 2,000 write/s |
| 平均read req/s | 200 req/s |
| 取引数 | 5B (50億)/月 |
| budget items | 100M (10M users × 10) |
| カテゴリ辞書サイズ | 約12 MB (5万seller) |
主要数値の可視化
write : read 比
read : write = 1:10 (write-heavy)
操作別 req/s
readwrite
write-heavy (10:1) 取引の取り込み(2,000/s)が参照(200/s)を大きく上回る。書き込みスループットと非同期集計が鍵。
まず自分で設計を考えてから、1ステップずつ答え合わせをしましょう。
Step 1: 要件・ユースケース（まだ伏せられています）
考えてみよう（面接官の追加質問）
- 金融機関連携が失敗(認証切れ・API変更)したとき、どうリトライ・通知する?
- 取引50 bytesは小さいが5B/月。1年で60B行になる。古い取引はどう扱う?(ヒント: Data Warehouseへ退避)
- カテゴリ分けを辞書ではなく機械学習でやる場合、辞書方式と比べた利点・欠点は?
- 『予算超過通知』をリアルタイムに近づけるには、取引書き込みの後どんな処理を足す?
- ユーザーが連携を解除したら、抽出済みの生ログ(Object Store)はどう削除する?(プライバシー観点)