短時間で100万ユーザーにプロモコードを送信するにはどうしますか？

Question

IT Interview Practice · Accepted Answer

リクエストハンドラー内で100万ユーザーをループしてはいけません。**キューを介してファンアウト**し、各プロバイダーが受け入れられる量にスロットリングし、すべての送信を**冪等（idempotent）**にし、失敗はリトライのためにDLQへ振り分けます。APIコールはエンキューするだけで、遅いI/Oはworkerが担当します。

## アーキテクチャ

```text
Admin ─▶ Campaign API ─▶ [enqueue job] ─▶ Kafka/SQS ─┐
                                                     ▼
   ┌──────────────── Worker pool (autoscaled) ───────────────┐
   │  claim ─▶ dedup(Redis SETNX) ─▶ rate-limiter ─▶ provider │
   └──────────┬──────────────────────────────┬───────────────┘
              │ ok                            │ fail (5xx/timeout)
              ▼                               ▼
        sent_log (DB)                    Retry (backoff) ─▶ DLQ
```

## コンポーネントと処理の流れ

- **Campaign API** はキャンペーンを書き込み、ジョブをエンキューします。キューのオーバーヘッドを削るため、ユーザーごと、あるいは**約500件のバッチ**ごとに1ジョブとします。即座にレスポンスを返し、100万件の送信はキューの背後で行われます。
- **キュー（Kafka / SQS）** はバッファであり、*リプレイ*ログでもあります。workerがクラッシュしてもメッセージは残り、コードが失われることはありません。`user_id` でパーティションを分け、ユーザーごとの順序を安定させます。
- **Worker pool** はジョブを取得し、キューの遅延（lag）に応じてオートスケールします。各workerは、(1) 一意のプロモコードを確保し、(2) Redisで**dedupキー** `SETNX sent:{campaign}:{user}` を確認して再配信されたメッセージが二重送信しないようにし、(3) プロバイダーのクォータに合わせた**rate limiter**を通し、(4) Email/SMS/Pushを呼び出します。
- **rate limiter** が肝心です。SendGridやTwilioは制限を超えるとスロットリングやブラックリスト化を行います。プロバイダーごとのRedisトークンバケットが、稼働中のworker数に関わらず送信RPSを制限します。
- **DLQ** は指数バックオフ + ジッターでN回リトライした後のpoisonメッセージを捕捉し、不正なアドレスがキャンペーン全体をブロックしないようにします。

## 面接での観点

面接官は、あなたが**デカップリングとバックプレッシャー**を理解しているかを探っています。「優れた」回答は具体的な障害を挙げます。冪等性がなければ、at-least-onceのキューとリトライの組み合わせでユーザーはコードを3通受け取ります。rate limiterがなければ、自らプロバイダーをDDoSしてスロットリングされゼロになります。よくある罠は、ファンアウトを同期的に行うこと（「`Promise.all` すればいい」）です。これは接続を占有し、リトライがなく、デプロイのたびにすべてを失います。

## トレードオフと障害

- **At-least-once対exactly-once**：キューは安価にat-least-onceを提供します。「実質的に一度」はRedisのdedupキーで買うのであって、高価なexactly-onceブローカーで買うのではありません。
- **スループット対プロバイダー制限**：workerは無限に追加できますが、プロバイダーのクォータが本当の上限です。キャンペーン前にクォータの引き上げを申請するか、事前ウォームアップします。
- **障害**：Redisダウン → 送信が停止（fail closedで、dedupをスキップして二重送信のリスクを冒さない）。キャンペーンごとのカウンターを追跡し、インシデント後に再開（restartではなくresume）できるようにします。

アーキテクチャ

コンポーネントと処理の流れ

面接での観点

トレードオフと障害

関連する質問