通知システム技術仕様書

概要

1百万以上のユーザーをサポートする、プッシュ通知、SMS、メールを扱う高信頼性の通知システムを設計する。システムは以下を保証する必要がある：

重複した通知がない
送信漏れがない
プロバイダー障害時の優雅な劣化
拡張性と監視可能性

高レベルアーキテクチャ

Client/API
   ↓
Notification Service
   ↓
Message Queue (Kafka/SQS/RabbitMQ)
   ↓
Notification Workers
   ↓
Provider Adapters
(SendGrid, Twilio, Firebase, etc.)
   ↓
Webhook/Event Processor
   ↓
Notification Database + Audit Logs

コアコンポーネント

1. 通知APIサービス

処理内容：

通知の作成
検証
一貫性チェック
メッセージのキューイング

各リクエストは以下を受け取ります：

通知ID
idempotency_key

サービスは処理前に通知を保存して、耐久性を確保します.

2. メッセージキュー

Kafka/SQS/RabbitMQは非同期処理に使用されます.

利点：

プロデューサーとコンシューマーを疎結合化
トラフィックのピークを吸収
再試行をサポート
リクエストのブロックを防止

メッセージは正常に処理されるまで保存されます.

3. 通知ワーカー

専用のワーカーとして:

メール
SMS
プッシュ通知

責任:

キューのメッセージを消費する
通知を送信する
一時的な失敗を再試行する
配送状況の更新

作業員が横方向にスケールします

信頼性戦略

一貫性

各通知には以下があります：

ユニークなnotification_id
一貫性キー

データベース制約：

UNIQUE(idempotency_key)

送信前に：

通知が既に成功したかどうかを確認
再試行中の重複送信を防止

再試行& エラー処理

エラーの分類:

一時的な → 再試行
恒久的な → 立即失敗

再試行戦略:

指数的バックオフ
死信キュー (DLQ)
最大再試行閾値

例：

1 min → 5 min → 15 min → 1 hour

優雅な劣化

プロバイダーが失敗した場合：

フォールバックプロバイダーが自動的にアクティベートされます

例：

Twilio fails → switch to Termii
SendGrid fails → switch to SES

遮断器は、不健康なプロバイダーへの継続的な呼び出しを防ぐ。

送り届けの追跡

ウェブフック処理機は受信：

届けられた
失敗した
バウンドした
開かれたイベント

全てのイベントは監査テーブルに保存されている。

データベース設計

テーブル：

通知
配送試行回数
提供者ログ
テンプレート
ユーザー設定

インデックス：

(user_id, created_at)
(status, channel)
(notification_id)

伝送漏れを防ぐ

メッセージのロスを避けるには：

キューイング前に保存された通知
トランザクショナルアウトボックスパターンを使用
再調整ジョブはブロックされた通知をスキャンします

例：

PENDING > 10 mins → requeue

観測可能性

監視：

キューの深さ
プロバイダの遅延
再試行回数
失敗した配信率

ツール：

Prometheus
Grafana
CloudWatch
Sentry

異常な失敗のスパイクでアラートがトリガーされます.

拡張性

システムは1M人以上のユーザーをサポートします：

横方向のワーカースケーリング
パーティション分割キュー
ステートレスサービス
Redisキャッシング
適用可能なバッチ処理

セキュリティ

暗号化されたプロバイダー資格情報
署名付きウェブフック
レートリミッティング
RBACによる管理者アクセス
すべての通知イベントの監査ログ

テックスタックの例

バックエンド: Node.js / Python
キュー: KafkaまたはSQS
データベース: PostgreSQL
キャッシュ: Redis
プロバイダー: Twilio, Firebase, SendGrid
モニタリング: Grafana + Prometheus
デプロイメント: Kubernetes/ECS

おすすめ購読元

DEV Community

概要