全社共通の通知サービスをどのように設計しますか？

Question

IT Interview Practice · Accepted Answer

すべてのチームが**通知タイプ + 受信者**を指定して呼び出す単一のサービスを構築し、チャネル、テンプレート、ユーザー設定、優先度の解決はサービスに任せます。設計上の鍵は**優先度レーン（priority lanes）**です。OTPが200万ユーザーへのマーケティング配信の後ろで待つことは許されません。

## アーキテクチャ

```text
Services ─▶ Notify API ─▶ [validate + enrich] ─▶ Kafka topics
                                                 ├─ otp/txn  (high lane)
                                                 └─ marketing (bulk lane)
                                                      │
                            ┌──── Dispatcher (per lane) ────┐
                            │ prefs check ─▶ template render │
                            └────┬──────┬──────┬────────────┘
                              Push   Email   SMS   In-App
                                 (provider adapters + rate limit)
```

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

- **Notify API** は型付けされたリクエストを受け取ります：`{type: "otp", user, data}`。呼び出し側はチャネルを選んだりコピーを書いたりしません。サービスがそれを所有するので、テンプレート変更は一度のリリースで済みます。
- **タイプ → ポリシー**：各**タイプ**はポリシーにマッピングされます。*OTP* は高優先度で、SMS+Push、マーケティングのオプトアウトを無視し、60秒で失効します。*トランザクション*（レシート、パスワードリセット）は高優先度で、チャネル設定を尊重します。*マーケティング*は低優先度、bulkレーンで、オプトアウトとサイレント時間を厳格に守ります。
- **優先度レーン**は、別々のconsumer groupを持つ別々のKafkaトピックです。highレーンはほぼ空のままミリ秒で捌かれ、bulkレーンはOTPのレイテンシに触れることなく数分間滞留できます。これが最も重要な決定です。
- **設定サービス（Preference service）**は受信者ごとにチェックされます。オプトアウトしているか？サイレント時間か？チャネルごとのトグルは？頻度上限は？設定に違反するマーケティングはここで破棄されます。
- **テンプレートエンジン**は、バージョン管理されたテンプレート + 変数からローカライズされたコンテンツをレンダリングし、コピーとコードを分離します。
- **チャネルアダプター**はFCM/APNs、SendGrid、Twilioを1つのインターフェースの背後にラップし、それぞれが独自のrate limiter、リトライ、DLQを持ちます（あらゆる一括送信と同じファンアウトの規律）。

## 面接での観点

面接官は、あなたが**関心事**を分離するかを探ります。多くの候補者はEmailを直接送信するモノリスを作り、後からマーケティングの洪水がOTPを遅延させることに気づきます。*優先度レーン*、*設定の強制*、*冪等キー*（リトライされたリクエストが二重通知しないよう）を挙げるのがシニアのシグナルです。「良い」回答はチャネルを追加しますが、「優れた」回答はなぜOTPとマーケティングが決してキューを共有してはいけないか、そして**フォールバックチェーン**（Push失敗 → SMS）がどう機能するかを説明します。

## トレードオフと障害

- **単一サービス対チーム別**：集約すれば一貫した設定、スロットリング、監査が得られますが、クリティカルな依存になります。HAでなければ、ログインOTPの障害が全社をブロックします。
- **リアルタイム対コスト**：SMSは高価で遅いです。Push/In-Appを優先し、高価値のタイプのみSMSにフォールバックします。
- **障害**：プロバイダー障害はハードな失敗ではなくフォールバックチェーンをトリガーします。**dedupキー**がキューの再配信によるOTPの二重送信を防ぎます。タイプごとの配信SLOを追跡します。遅延したマーケティングメールは問題ありませんが、遅延したOTPはインシデントです。

アーキテクチャ

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

面接での観点

トレードオフと障害

関連する質問