システム設計：リアルタイム通知サービス

リアルタイム通知サービス — システム設計計画

1. 要件の再確認と容量見積もり

トラフィック計算:

• 1億DAU x 1日あたり10イベント = 1日あたり10億件の通知トリガーイベント。
• 平均 = 10億 / 86,400 ≈ 11,600 イベント/秒。ピーク時は5倍 ≈ 58,000 イベント/秒。
• ファンアウト乗数: ほとんどのイベント（いいね、コメント、フォロー、DM）は正確に1人の受信者を対象とするため、ファンアウトは〜1:1です。ただし、フォロワー数の多いアカウント（有名人の投稿）からのイベントは数百万人の受信者にファンアウトする可能性があります。これらは別の「バルクファンアウト」パスとして扱います。バルクキャンペーンを含め、ピーク時の配信能力を80,000〜100,000件/秒と想定します。
• ストレージ: ユーザーあたり過去100件の通知履歴。1行あたり約400バイトと仮定 -> 100 x 400B = 40KB/ユーザー -> 1億ユーザー ≈ 4TBのホット履歴、レプリケーション係数3で約12TB。容易にシャーディング可能。
• 接続数: ピーク時にDAUの20〜25％がオンラインであると仮定 ≈ 20〜25MのライブWebSocket接続。ゲートウェイノードあたり約100K接続（チューニングされたLinux、epoll）で、200〜250ノードプラス余裕があります。

非機能要件ターゲット:

• オンラインユーザーのエンドツーエンドp99レイテンシは2秒未満（イベント取り込みからクライアントackまでを測定）。
• 99.9%の可用性 = 月あたり約43分のダウンタイム。
• クライアント/サーバーサイドのべき等重複排除による少なくとも1回の配信。

2. 高レベルアーキテクチャ

この設計は、取り込みパス（高速、耐久性、書き込み最適化）と配信パス（チャネル固有、リトライ可能）を明確に分割したイベント駆動型パイプラインです。

フロー:
プロデューサーサービス（投稿サービス、ソーシャルグラフサービス、コメントサービス、メッセージングサービス）
-> 通知API/ゲートウェイ（gRPC + REST、認証、レート制限、スキーマ検証、べき等キー）
-> Kafkaトピック notification.events（受信者ユーザーIDがわかっている場合はそれ、不明な場合はアクターIDでパーティション分割）
-> ファンアウトサービス（受信者を解決し、有名人イベントを展開し、集約ルールを適用）
-> Kafkaトピック notification.deliveries（受信者ごとに1メッセージ）
-> 設定とポリシーサービス（キャッシュ経由のインラインルックアップ：チャネルオプトイン、サイレントアワー、ミュート/ブロック、ダイジェストかインスタントか）
-> ルーター/ディスパッチャーがチャネルごとのトピックに書き込み:
deliver.websocket, deliver.mobile_push, deliver.web_push, deliver.email
-> チャネルワーカー:
WebSocketディスパッチャー -> 接続レジストリールックアップ -> リアルタイムゲートウェイノード -> クライアント
モバイルプッシュワーカー -> APNs (iOS) / FCM (Android)
Webプッシュワーカー -> ブラウザプッシュサービス経由のVAPID/Web Pushプロトコル
メールワーカー -> SES / SendGrid、テンプレートレンダリングとダイジェストバッチ処理付き
-> 並行して、履歴ライターコンシューマーがすべての配信を通知履歴ストアに永続化し、未読カウンターをインクリメントします。

横断的なコンポーネント: テンプレートサービス、デバイスレジストリ、接続レジストリ、重複排除ストア、デッドレターキュー、オブザーバビリティスタック、および同じKafkaストリームを消費する管理者/分析プレーン。

3. 主要コンポーネントと責任

通知APIゲートウェイ

• 内部プロデューサー（gRPC、レジストリ内のprotobufスキーマ）およびクライアント読み取りAPI（履歴、既読マーク、設定用のREST/GraphQL）の単一のエントリポイント。
• 責任: 認証（サービス間mTLS、クライアント用JWT）、テナントごとおよびプロデューサーごとのレート制限/クォータ、リクエスト検証、べき等キーの受け入れ、およびKafkaへの即時耐久性のある追記。すぐに202 Acceptedを返します。インラインで配信作業は行いません。

イベント取り込み/Kafka

• 耐久性があり、再生可能なログ。notification.eventsは、約256パーティション、レプリケーション係数3、min.insync.replicas=2、acks=all、保持期間7日間で、再生とインシデント回復に使用します。
• プロデューサーと低速なサードパーティプロバイダーを分離し、5倍のピークに対する自然なバックプレッシャーとバッファリングを提供します。

ファンアウトサービス

• イベントを受信者リストに解決します。1:1イベントの場合はパススルーです。1:Nイベント（フォロワーへの新しい投稿、グループスレッドアクティビティ）の場合は、ソーシャルグラフサービスをページングし、受信者メッセージをバッチで発行します。
• ハイブリッドファンアウト戦略: 通常のアカウントの場合はプッシュベース（受信者ごとに書き込み）、フォロワー数がしきい値（例: 100万人以上）を超えるアカウントの場合はプルベース/遅延実行（読み取り時に受信者が具体化される単一の「フィードマーカー」を書き込みます）。これにより、有名人のイベントがホットパスで5000万メッセージの書き込みストームを生成するのを防ぎます。
• バルク展開を別の低優先度Kafkaトピックにレート制限するため、インタラクティブ通知を決して飢えさせません。
• 集約/合算の適用: 25件の行ではなく、「アリスと他の24人があなたの投稿にいいねしました」のように、(受信者、投稿ID、タイプ)をキーとする短いタンブリングウィンドウ（例: 30〜60秒）をRedisで使用します。

設定とポリシーサービス

• ユーザーごとのチャネル設定、カテゴリレベルのオプトイン、タイムゾーン付きのサイレントアワー、デバイスレベルの設定、ミュート/ブロックリスト、および法的同意フラグ（GDPR/CAN-SPAM）を保存および提供します。
• 読み取りパスはRedisにキャッシュされ、ライトスルー無効化が行われます。p99ルックアップターゲットは5ミリ秒未満です。ソースオブトゥルースはリレーショナルストアにあります。
• ユーザーエクスペリエンスとプロバイダーのクォータを保護するため、周波数キャッピング（例: ユーザーあたり最大N回のプッシュ/時間）を強制します。

ルーター/ディスパッチャー

• 承認された配信をチャネル固有の作業項目にマッピングします。接続レジストリを使用して「オンラインの場合はアプリ内+WebSocketのみ。それ以外の場合はモバイルプッシュ」を決定し、設定に応じてインスタント送信の代わりにメールダイジェストをスケジュールします。

リアルタイムゲートウェイ（WebSocketレイヤー）

• WebSocket接続を保持するステートフルティア（フォールバック: Server-Sent Events、次にロングポーリング）。
• 接続時: 認証、登録（user_id、device_id） -> 接続レジストリ（Redis Cluster、TTL +ハートビート更新）内のgateway_node_id、その後、未読バックログをプッシュします。
• 配信時: ディスパッチャーがノードをルックアップし、内部gRPCストリームまたはノードごとのKafka/Redis Pub/Subチャネル経由で送信します。ゲートウェイはソケットに書き込み、クライアントackを待ちます。
• 30秒ごとのハートビート。ハートビートの欠落はレジストリエントリをエビクトし、将来の通知は自動的にモバイルプッシュにフォールバックします。

チャネルワーカー

• モバイルプッシュワーカー: APNs（HTTP/2多重化、トークンベース認証）およびFCMへのバッチ処理。プロバイダーごとの同時実行制限、指数バックオフとジッターを処理し、デバイスレジストリから無効または未登録のデバイストークンを削除します。
• Webプッシュワーカー: VAPIDキーとペイロード暗号化を備えたWeb Pushプロトコル。
• メールワーカー: テンプレートをレンダリングし、インスタント、毎時、毎日のダイジェストをサポートします。プロバイダーのWebhook経由でバウンス/苦情を処理し、抑制リストを維持します。
• すべてのワーカーは、notification_idをキーとするべき等コンシューマーであり、最終ステータスをdelivery.statusトピックに書き戻します。

履歴ライターと読み取りパス

• 通知を永続化し、Redisで未読カウンターを維持するコンシューマー（カウンターはストアから定期的に同期されます）。
• 読み取りAPIは履歴ストアから最後の100件の通知を提供し、ユーザーごとの最初のページのRedisキャッシュを備えており、通常の読み取りは10ミリ秒未満です。

サポートサービス

• テンプレートサービス: バージョン管理されたローカライズされたテンプレートと変数補間。コードのデプロイからコピーの変更を分離します。
• デバイスレジストリ: device_token、プラットフォーム、app_version、ロケール、タイムゾーン、最終アクセス時刻。
• 重複排除ストア: Redis、(producer_id, idempotency_key)に24時間TTLを設定し、少なくとも1回の配信を実質的に1回として機能させます。
• スケジューラー: 遅延/スケジュールされた通知とダイジェストウィンドウ用（Redisソートセット内の時間バケット化されたキューまたはKafka遅延トピックラダーのような専用スケジューラー）。
• DLQ + リプレイヤー: 問題のあるメッセージは、修正後に一時停止され、再生可能になります。

4. データモデルとデータベースの選択

a) 通知履歴 — Cassandra（またはScyllaDB / DynamoDB）
テーブル: notifications_by_user

• パーティションキー: user_id
• クラスタリングキー: created_at DESC, notification_id
• カラム: type, actor_id(s), target_type, target_id, aggregated_count, preview_text, image_url, deep_link, read_at, channels_sent, created_at
• TTL: 90日。アプリケーションは読み取りを100行に制限します。
  正当性: アクセスパターンは、単一のよく知られたパーティションキーと時間順のスライスです。これはCassandraの得意分野です。書き込みのスケーラビリティ（毎秒60〜100K件の書き込みが必要）、可用性のためのマルチリージョンマスターレスレプリケーション、調整可能な一貫性（書き込みQUORUM/LOCAL_QUORUM、読み取りLOCAL_ONE）、および保持のためのネイティブTTLを提供します。結合や複数行トランザクションは不要なため、リレーショナルストアはシャーディングの苦痛と書き込み増幅のリスクを増やすだけです。

b) 未読カウンターとホットな最初のページ — Redis Cluster

• unread:{user_id}整数カウンター。notif:page0:{user_id}キャッシュされたJSONリスト。
  正当性: カウンターはアプリを開くたびに読み取られ（非常に高いQPS、読み取りあたりの値は低い）、単桁ミリ秒である必要があります。Redisはこれを安価に吸収します。Cassandraカウンターは比較的高価でエラーが発生しやすいです。カウンターは非同期に同期されるため、ドリフトは自己修復します。

c) ユーザー設定とデバイストークン — PostgreSQL（user_idでシャーディング）とRedis読み取りスルーキャッシュ
テーブル: user_preferences(user_id, category, channel, enabled, quiet_hours_start, quiet_hours_end, timezone, updated_at), devices(device_id, user_id, platform, push_token, locale, last_seen, active), suppression_list(email, reason, created_at)。
正当性: このデータは低ボリューム、読み取りヘビー、リレーショナル（ユーザー -> デバイス -> カテゴリごとの設定）であり、正確性と監査可能性（同意レコードにはコンプライアンスの重みがある）のためのトランザクションと制約から利益を得ます。ボリュームは小さく（約1億行）、容易にシャーディングでき、ほとんどすべてをキャッシュできます。

d) 接続レジストリ — Redis Cluster

• conn:{user_id} -> {device_id, gateway_node_id, connected_at}のセット、TTL 90秒、ハートビートで更新。
  正当性: 一時的で、非常に高いチャーン率、高速である必要があります。耐久性は不要です。エントリが失われた場合、プッシュフォールバックに正常に低下するためです。

e) 重複排除/べき等性 — TTL付きRedis、バックアップなし（損失はまれな重複のリスクのみ）。

f) テンプレートと設定 — PostgreSQL + アセット用のオブジェクトストレージ、エッジでキャッシュ。

g) 分析 — Kafkaからデータレイク（S3/Parquet）およびウェアハウス（Snowflake/BigQuery）にストリーミングされるイベント、配信率、開封率、レイテンシレポート用。ニアリアルタイム運用ダッシュボード用ClickHouse。

5. テクノロジースタックの推奨事項

• 言語/ランタイム: Go（ゲートウェイ、リアルタイムゲートウェイ、ワーカー用。ゴルーチンと低メモリ/接続が数百万のソケットに適しています）。Java/Kotlin（Kafka Streams中心の集約には許容範囲）。
• メッセージング: Apache Kafka（マネージド: MSK/Confluent）をバックボーンとして使用。チャネルごとおよび優先度クラスごとに別々のトピック。
• リアルタイムトランスポート: TLS経由のWebSocket、SSEおよびロングポーリングのフォールバック付き。NLB/L4ロードバランシング（接続ドレイン付き）。スティッキーローティングは不要（レジストリがノードIDを格納するため）。
• キャッシュ: Redis Cluster（またはElasticache/MemoryDB）（カウンター、設定、レジストリ、重複排除、レート制限用）。
• データストア: Cassandra/ScyllaDB（履歴用）。PostgreSQL（Aurora）（設定/デバイス用）。S3 + ウェアハウス（分析用）。
• プッシュプロバイダー: APNs、FCM、Web Push（VAPID）。SES経由のメール（SendGridをフェイルオーバー用のプロバイダー抽象化レイヤーの後ろのセカンダリプロバイダーとして使用）。
• インフラストラクチャ: Kubernetes（HPA/KEDAによるKafkaコンシューマーラグ（CPUだけでなく）でのスケーリング付き）、Envoy/Istioサービスメッシュ（mTLSおよびリトライ用）、Terraform（IaC用）。
• オブザーバビリティ: OpenTelemetryトレーシング（プロデューサーイベントからクライアントackまで伝播されるトレースID）、Prometheus + Grafanaメトリクス、Loki/ELKでの構造化ログ、SLOに対するPagerDutyアラート。
• 信頼性ライブラリ: 各外部プロバイダーのサーキットブレーカーとバルクヘッド、トークンバケットレートリミッター、ジッター付き指数バックオフ。

6. スケーラビリティ、レイテンシ、および可用性の戦略

スケーラビリティ

• すべてのステートレスコンポーネント（API、ファンアウト、ルーター、ワーカー）は水平にスケールします。Kafkaパーティション数は並列処理の天井となるため、初日から現在のピークの5〜10倍のパーティションをプロビジョニングします（再パーティション分割は運用上困難です）。
• KEDAによるコンシューマーラグのスケーリング。5倍のスパイクが数秒以内にスケールアウトをトリガーするようにします。スケーリングは即時ではないため、30〜40％のヘッドルームのウォームバッファを維持します。
• Cassandra、Postgres、Redis全体でuser_idによる一貫したシャーディング。これにより、単一ユーザーのデータが共locatされ、ホットパーティションの緩和が均一になります。
• 優先度レーン: インタラクティブ通知（DM、自分の投稿へのコメント）は専用コンシューマーグループを持つ高優先度トピックを使用します。バルク/マーケティング/有名人ファンアウトは、スロットルされた低優先度レーンを使用します。これにより、ユーザーが実際に気にする通知の2秒SLOが保証されます。
• ハイブリッドプッシュ/プルファンアウト（前述）および非常にホットなターゲット用のソルトパーティションキーによる有名人/ホットキー処理。

低レイテンシ（p99 2秒未満）

• クリティカルパスは意図的に短くされています: API書き込み -> Kafka -> ファンアウト -> 設定キャッシュヒット -> レジストリールックアップ -> WebSocket書き込み。すべてのルックアップはRedis（5ミリ秒未満）で行われ、同期データベース書き込みは配信をブロックしません。
• 履歴の永続化と分析は非同期であり、配信パスから外れています。
• Kafkaプロデューサーは、レイテンシとバッチ処理のバランスを取るためにlinger.ms=5と圧縮（lz4）でチューニングされています。コンシューマーは処理後に手動コミットを使用します。
• ユーザーを最も近いリージョンにピン留めしたマルチリージョンデプロイメントにより、RTTを削減します。WebSocket接続はリージョンエッジで終了します。
• 集約ウィンドウはタイプごとに設定可能で、DMのようなレイテンシクリティカルなタイプでは無効になります。
• 継続的な合成プローブにより、リージョンごとおよびチャネルごとの実際のエンドツーエンドレイテンシを測定します。

高可用性（99.9%以上）

• 単一障害点はありません: すべてのティアでマルチAZ、Kafka RF=3（min.insync.replicas=2）、Cassandra RF=3（LOCAL_QUORUM書き込み）、Postgres（同期スタンバイと自動フェイルオーバー付き）。
• リアルタイムおよび配信ティアのアクティブ/アクティブマルチリージョン。Cassandraはクロスリージョンを非同期にレプリケートし、Postgresはリージョンごとの読み取りレプリカを使用し、指定された書き込みリージョンがあります。
• グレースフルデグラデーションラダー: WebSocketパスが正常でない場合はモバイルプッシュにフォールバックします。設定キャッシュがダウンしている場合はPostgresにフォールバックし、その後保守的なデフォルトにフォールバックします。Cassandraの書き込みが失敗した場合は、リアルタイム配信を継続し、後でKafkaから履歴書き込みを再生します。
• ジッター付き指数バックオフによるリトライ、キャップされた試行、その後DLQ（アラートと再生ツール付き）。
• 外部プロバイダーごとのサーキットブレーカー。APNsの障害がワーカー スレッドを枯渇させ、メールを停止させるのを防ぎます。
• 少なくとも1回の配信と、サーバーおよびクライアントでのnotification_idによる重複排除。クライアントは、未読バックログを再生する際に再接続時にも重複排除を行います。
• 信頼性のプラクティス: カオス/ゲームデー演習（ゲートウェイノードをキルしてプッシュフォールバックを確認）、ピーク時の5倍の負荷テスト、ブルー/グリーンおよびカナリアデプロイ、チャネルごとのキルスイッチのフィーチャーフラグ、高優先度トラフィックの前に低優先度トラフィックをドロップするバックプレッシャー。

7. ボトルネックとトレードオフ

潜在的なボトルネック

• サードパーティプロバイダー（APNs/FCM/メール）: スループットを制御できないため、最も厳しい制約です。HTTP/2経由の接続プーリング、バッチ処理、プロバイダーごとのレートリミッター、メールのマルチプロバイダーフェイルオーバー、およびスパイクのキューベースの平滑化で軽減します。
• 有名人ファンアウト: 単一の投稿で数千万件の配信が発生する可能性があります。ハイブリッドプッシュ/プル、スロットルされたバルクレーン、および集約によって軽減されます。
• WebSocket接続ティア: ノードあたりのメモリとファイルディスクリプタ、およびデプロイやネットワークの瞬断後のサンダーシングハードリコネクト。チューニングされたカーネル制限、ジッターと指数バックオフによるクライアントサイド強制リコネクト、デプロイ中の接続ドレインの遅延で軽減します。
• Redisホットキー: バイラル投稿の集約キーまたは共有カウンター。キーの塩漬け、短いTTLを持つローカルインプロセスキャッシュ、およびクライアントサイドシャーディングで軽減します。
• 毎秒10万件の書き込みでのCassandra書き込み増幅とコンパクション圧力。時間ウィンドウコンパクション（TWCS）を時間系列TTLデータに適したものにし、低価値の通知タイプを履歴に格納しないことで軽減します。
• 低カーディナリティキーによるパーティションの偏り。常に配信トピックでrecipient_user_idでパーティション分割します。

明示的なトレードオフ

• 完全に一度（exactly-once）よりも少なくとも一度（at-least-once）: 異種外部プロバイダー全体での完全に一度は非現実的でコストがかかります。まれな重複を受け入れ、べき等キーとクライアントサイドの重複排除で解決します。これはより安価で、はるかに利用可能です。
• カウンターと履歴の最終的な一貫性（eventual consistency）対強い一貫性: 一時的に1つずれている未読バッジは許容できます。それを保証するために数秒のレイテンシは許容できません。同期ジョブがドリフトを制限します。
• 単一データベースに対するポリグロット永続化: 運用上のサーフェス（3つのデータストアとRedis）が増えますが、各ワークロードは適切なエンジンを得ます。単一のPostgresクラスタは、1日あたり10億件の書き込みでボトルネックになります。単一のCassandraクラスタでは、設定と同意監査が厄介になります。
• ほとんどのユーザーに対するプッシュベースのファンアウト、有名人に対するプルベース: コードの複雑さが増しますが、無限の書き込みストームを回避する唯一の方法です。
• 集約はユーザーエクスペリエンスを向上させ、配信量を劇的に削減しますが、集約可能なタイプにはウィンドウの遅延が追加されます。ウィンドウは短く保ち、DMは除外します。
• マルチリージョンアクティブ/アクティブはコストを増加させ、クロスリージョンの一貫性の微妙さを導入しますが、可用性とレイテンシのターゲットによって正当化されます。予算が制約されている場合、単一リージョン（ウォームスタンバイ付き）の姿勢でも99.9%を満たしますが、RTOは長くなります。
• 単純なマネージドキュー（SQS）よりもKafka: 運用上の負担は大きいですが、再生、キーごとの順序付けされたパーティション、複数の独立したコンシューマーグループ、およびインシデント回復のための7日間の保持が必要です。
• 過去約100件の通知のみを90日間のTTLで格納することは、コストと読み取りパフォーマンスのためにアーカイブの完全性を犠牲にします。長期データは、必要に応じて分析レイクに保存されます。

8. ロールアウト計画（段階的）

フェーズ1: 取り込みAPI + Kafka + 履歴ライター + 読み取りAPI（アプリ内通知のみ）。耐久性のあるバックボーンを確立します。
フェーズ2: リアルタイムゲートウェイ、接続レジストリ、未読カウンター、プッシュフォールバック付きWebSocket配信。
フェーズ3: モバイルプッシュおよびWebプッシュワーカー、デバイスレジストリ、設定サービスおよびサイレントアワー。
フェーズ4: メールインスタント+ダイジェスト、テンプレートサービス、抑制処理。
フェーズ5: 集約/合算、ハイブリッド有名人ファンアウト、周波数キャッピング。
フェーズ6: マルチリージョンアクティブ/アクティブ、カオスエンジニアリング、ピーク時の5倍の負荷検証、SLOダッシュボードとエラーバジェット。

9. 主要メトリクスとSLO

• チャネルごとのエンドツーエンドp50/p95/p99レイテンシ（SLO: WebSocketでp99 2秒未満）。
• チャネルごとの配信成功率。プロバイダーのエラー率とトークン無効化率。
• Kafkaコンシューマーラグ（トピックごと）（主要な自動スケーリングおよびページングシグナル）。
• WebSocket接続数、チャーン率、ack率。
• 同期によって検出された未読カウンターのドリフト。
• DLQの深さと経過時間。
• クライアントの観点から測定されたAPIごとの可用性。月間エラーバジェットに対する追跡。

ハイレベルアーキテクチャ:

システムはイベント駆動型です。フォローサービス、投稿サービス、コメントサービス、リアクションサービス、ダイレクトメッセージサービスなどのプロダクトサービスは、通知トリガーイベントを耐久性のあるメッセージバスに発行します。通知パイプラインはこれらのイベントを消費し、エンリッチし、ユーザー設定と重複排除ルールを適用し、通知レコードを永続化し、リアルタイムのWebSocket/Webプッシュ、モバイルプッシュ、および電子メール配信ジョブをチャネル固有の配信ワーカーにルーティングします。

コアフロー:

1. ユーザーアクションが発生します。例：ユーザーAがユーザーBの投稿に「いいね！」をします。
2. ソースサービスは、自身のビジネストランザクションを書き込み、アウトボックスパターンまたはトランザクションイベントログを使用して、通知イベントをメッセージブローカーに発行します。
3. 通知取り込みサービスは、イベントを検証し、共通スキーマに正規化し、冪等性キーを割り当てます。
4. ファンアウトおよびルーティングサービスは、受信者、通知タイプ、優先度、チャネル適格性、および受信者がオンラインかどうかを決定します。
5. 通知ストレージサービスは、通知を受信者の通知履歴に書き込みます。
6. リアルタイム配信は、オンラインのWeb/アプリユーザーの場合はWebSocket接続を介して、適切な場合はモバイルデバイスの場合はモバイルプッシュを介して試行されます。
7. 電子メール配信は、ユーザーへのスパム送信を避けるために、通常はバッチ処理と低優先度で個別にキューイングされます。
8. 配信ステータス、再試行、失敗、およびメトリクスは非同期に追跡されます。

スケール推定:

DAU 1億人 × 1日あたりのイベント数 10件 = 1日あたりの通知トリガーイベント数 10億件。平均イベントレートは約 11,600 イベント/秒です。ピーク時の負荷は 5倍で約 58,000 イベント/秒です。設計では、特にコメント、メンション、グループ会話、ライブインタラクションの場合、1つのイベントが複数の受信者に通知する可能性があるため、内部ファンアウトを考慮する必要があります。安全な初期ターゲットは、ピーク時に 100,000 ～ 300,000 件の通知配信/秒になる可能性がありますが、これはプロダクトの動作によって異なります。

主要コンポーネントと責任:

1. APIゲートウェイ
   通知履歴の読み取り、通知の既読化、通知設定の更新、デバイスの登録、WebSocket接続の確立などの外部APIリクエストを受け付けます。認証、レート制限、リクエストルーティング、および基本的な不正利用保護を処理します。

2. イベントプロデューサー
   既存のプロダクトサービスは、UserFollowed、PostLiked、CommentCreated、UserMentioned、DirectMessageCreated、MessageReactionAddedなどのドメインイベントを生成します。プロデューサーは、通知配信サービスを同期的に呼び出すべきではありません。これは、プロダクトのレイテンシが通知インフラストラクチャに依存してしまうためです。プロデューサーは耐久性のあるイベントバスに発行します。

3. イベントバスまたはメッセージキュー
   Apache KafkaやApache Pulsarなどの分散ログが推奨されます。高スループット、耐久性のあるストレージ、再生機能、パーティショニング、コンシューマーグループ、バックプレッシャー処理を提供します。トピックは、イベントファミリーまたは優先度（例：social-interactions、direct-messages、notification-delivery-high、notification-delivery-normal、notification-delivery-email）ごとに分離できます。

4. 通知取り込みサービス
   生のプロダクトイベントを消費し、スキーマを検証し、該当する場合は無効な/自己通知をフィルタリングし、イベントペイロードを正規化し、通知IDを生成し、冪等性チェックを実行します。また、アクター名、アクターアバター参照、投稿ID、ターゲットオブジェクトタイプなどの軽量メタデータでイベントをエンリッチします。重いエンリッチメントは、レイテンシを保護するために最小限にするか、非同期で行う必要があります。

5. ファンアウトサービス
   受信者を決定し、受信者ごとの通知タスクを作成します。いいね、フォロー、ダイレクトメッセージなどの1対1イベントの場合、ファンアウトは単純です。メンション、グループメッセージ、コメントスレッドなど、複数の受信者が関与するイベントの場合、ファンアウトは多数の配信レコードを生成する可能性があります。スケールに応じて、ファンアウトオンライトとファンアウトオンリードの両方をサポートする必要があります。
   推奨アプローチ:
   通常の通知の場合は、ファンアウトオンライトを使用し、受信者ごとの通知レコードを保存します。これにより、履歴の取得が高速になり、未読カウントが可能になります。
   非常に高いファンアウトエンティティ（有名人の放送や大規模なグループなど）の場合は、ハイブリッドファンアウトを使用します。共有通知オブジェクトを保存し、アクティブユーザー向けにのみ、または読み取り時にマテリアライズします。

6. 設定およびポリシーサービス
   ユーザーの通知設定、プライバシー設定、ミュート/ブロック関係、サイレントアワー、チャネル権限、ロケール、メールオプトインステータス、およびプラットフォーム固有の設定を保存および評価します。チャネルの適格性と優先度を返します。設定は積極的にキャッシュする必要があります。

7. 通知ストアサービス
   通知履歴と状態を永続化します。最後のN件の通知、未読/既読ステータス、タイムスタンプ、タイプ、アクター、エンティティ参照、およびレンダリングメタデータを保存します。ユーザーの最新100件の通知、未読カウント、1件既読化、すべて既読化、削除/非表示などのクエリをサポートします。

8. リアルタイム接続ゲートウェイ
   オンラインのWebおよびモバイルアプリユーザー向けのWebSocketまたはServer-Sent Events接続を維持します。接続のプレゼンスを分散プレゼンスストアに保存します。配信ワーカーは、受信者のアクティブな接続を保持しているゲートウェイノードにリアルタイム通知をルーティングします。バックグラウンドのモバイルアプリの場合、配信はAPNs/FCMにフォールバックします。

9. プレゼンスサービス
   ユーザーがオンラインかどうか、どのデバイスが接続されているか、どのゲートウェイノードが各接続を所有しているかを追跡します。プレゼンスデータは一時的なものであり、短いTTLハートビートを持つRedis Clusterまたはその他の低レイテンシ分散キャッシュに保存する必要があります。

10. チャネル配信サービス
    個別のワーカーがチャネルごとに通知を配信します。
    モバイルプッシュワーカー：iOSの場合はAPNs、Androidの場合はFCMに送信します。トークン無効化、プロバイダーエラー、再試行可能な失敗、および折りたたみキーを処理します。
    Webプッシュワーカー：登録済みブラウザサブスクリプションを持つユーザーに対して、Webプッシュプロトコルを介してブラウザプッシュを送信します。
    WebSocketワーカー：リアルタイムゲートウェイを介して、オンラインユーザーに低レイテンシのアプリ内通知を送信します。
    メールワーカー：SES、SendGrid、または内部MTAなどのプロバイダーを介してメールを送信します。バッチ処理、テンプレート、購読解除ルール、および低優先度キューをサポートする必要があります。

11. デバイス・トークン・サービス
    モバイルデバイスのトークン、ブラウザプッシュサブスクリプション、デバイスメタデータ、アプリバージョン、プラットフォーム、ロケール、および最終アクセス時刻を保存します。トークンのローテーションと無効なトークンのクリーンアップを処理します。

12. テンプレートおよびローカライゼーションサービス
    通知タイプ、ロケール、アクター、オブジェクトメタデータ、およびクライアント機能に基づいて、通知テキストとメールテンプレートをレンダリングします。アプリ内履歴の場合は読み取り時にレンダリングするために構造化された通知データを保存し、プッシュ/メールの最終ペイロードを配信時にレンダリングすることを優先します。

13. 重複排除および集約サービス
    スパムや重複通知を防ぎます。例：「Aliceと他の12人があなたの投稿に「いいね！」をしました」と、13件の個別のプッシュ通知を送信するのではなく集約します。idempotency_key（例：event_type + actor_id + recipient_id + object_id + event_time_bucket）を使用します。集約は、Redisのソート済みセット/カウンターを使用して実行し、その後永続化できます。

14. メトリクス、ロギング、およびアラート
    エンドツーエンドのレイテンシ、キューラグ、配信成功率、プロバイダーエラー率、WebSocket接続数、通知作成率、ファンアウトファクター、データベースレイテンシ、未読カウントの精度、および再試行/デッドレターキューのボリュームを収集します。

データモデル:

1. 通知イベントスキーマ
   notification_event_id: グローバルに一意なID
   source_event_id: ソースサービスのID
   event_type: follow, like, comment, direct_message, mention
   actor_user_id: イベントを引き起こしたユーザー
   recipient_user_ids または受信者リゾルバー参照
   target_type: post, comment, user, message, conversation
   target_id: ターゲットオブジェクトID
   created_at: イベント発生時刻
   metadata: 追加コンテキスト用のコンパクトなJSON
   idempotency_key: 重複防止のための安定したキー
   priority: high, normal, low

2. 通知履歴レコード
   user_id: 受信者のパーティションキー
   notification_id: 時間ソート可能な一意なID（例：Snowflake/UUIDv7）
   notification_type
   actor_user_id またはアクターの概要
   target_type
   target_id
   aggregation_key
   summary_text またはレンダリングパラメータ
   created_at
   read_at (nullable)
   seen_at (nullable)
   status: created, delivered, failed, hidden
   channels_attempted
   metadata

履歴ストレージには、Apache Cassandra、ScyllaDB、またはDynamoDBのようなワイドカラムストアを使用します。user_idでパーティション化し、created_atの降順またはnotification_idの降順でクラスタリングします。これは、プライマリクエリパターン（ユーザーの最新100件の通知を取得する）に一致します。水平方向にスケーリングし、高書き込みスループットをサポートし、予測可能な低レイテンシの読み取りを提供します。プロダクト要件に従って最近の履歴を保持するためにTTLまたはバックグラウンドコンパクションを使用しますが、少なくとも最新の100件は保持します。厳密な「最新100件のみ」が必要な場合は、ユーザーごとのトリムジョブを維持するか、TTLと定期的なコンパクションを使用します。

論理テーブルの例:
UserNotifications
パーティションキー: user_id
クラスタリングキー: created_at 降順, notification_id
カラム: type, actor_user_id, target_type, target_id, metadata, read_at, aggregation_key, status

3. 未読カウントモデル
   未読カウントの読み取りと書き込みを高速に行うためにRedisを使用し、Cassandra/DynamoDBの耐久性のあるストレージをバックエンドとします。通知作成時にインクリメントし、読み取り/すべて既読化時にデクリメントまたはリセットします。カウンターはドリフトする可能性があるため、耐久性のあるストレージから定期的に調整するか、読み取りマーカーモデルを使用します。
   代替読み取りマーカーアプローチ:
   ユーザーごとのlast_read_timestampを保存し、それよりも新しい通知を未読とみなします。これにより、「すべて既読化」が安価になります。通知ごとの既読ステータスの場合は、個々のレコードにread_atを保存します。ハイブリッドが最適な場合が多いです。

4. ユーザー設定
   設定は一貫性、構造化された更新、および時折の結合/管理操作を必要とするため、耐久性のある設定レコードにはPostgreSQLやMySQLなどのリレーショナルデータベースを使用します。ホットな設定はRedisまたはMemcachedでキャッシュします。非常に大規模なスケールの場合、user_idでシャーディングするか、組織がマネージドキーバリュースケールを好む場合はDynamoDBを使用します。

設定スキーマ:
user_id
notification_type
channel: push, web, email, in_app
enabled: boolean
quiet_hours
frequency: immediate, digest, never
updated_at

5. デバイス・トークンおよびプッシュサブスクリプション
   user_idとdevice_idをキーとするDynamoDB、Cassandra、またはシャーディングされたリレーショナルストアを使用します。トークンルックアップは高速かつ高可用性である必要があります。token_hash/token、platform、app_version、locale、enabled、last_seen_at、およびinvalidated_atを保存します。

6. プレゼンスデータ
   Redis ClusterをTTLで使用します:
   user_id -> アクティブな接続ID、デバイスID、ゲートウェイノードID、最終ハートビート
   connection_id -> user_id、ゲートウェイノード、有効期限
   プレゼンスはリアルタイム配信の最適化にすぎないため、結果整合性で構いません。

7. 配信ステータスおよび監査ログ
   Kafkaトピックと、運用デバッグ、分析、配信レポート用の低コスト分析ストア（S3/オブジェクトストレージ、ClickHouse、BigQuery、またはElasticsearch/OpenSearchなど）を使用します。高ボリュームの配信ログは、プライマリトランザクションストアに配置しないでください（必要な場合を除く）。

テクノロジースタックの推奨事項:

メッセージブローカー：KafkaまたはPulsar（耐久性のあるイベントストリーミング用）、受信者ごとの順序が重要な場合はrecipient_user_idでパーティション化します。取り込み、ファンアウト、チャネル配信、再試行、およびデッドレターキューごとに別々のトピックを使用します。

データベース：
通知履歴にはCassandra/ScyllaDB/DynamoDB。
ユーザー設定にはPostgreSQL/MySQLまたはDynamoDB。
プレゼンス、未読カウントキャッシュ、冪等性短期キャッシュ、レート制限、および集約ウィンドウにはRedis Cluster。
ログおよび履歴分析にはオブジェクトストレージと分析データベース。

リアルタイムトランスポート：
アプリ内およびWebリアルタイム通知にはWebSocket。Server-Sent EventsはWeb専用の一方向配信に使用できますが、WebSocketは確認応答とハートビートに対してより柔軟です。

プッシュプロバイダー：
iOSの場合はAPNs、Androidの場合はFCM、ブラウザの場合はWebプッシュ。プロバイダー固有の動作を分離するために、プッシュ配信サービスの後ろにプロバイダーを抽象化します。

電子メール：
Amazon SES、SendGrid、Mailgun、または内部メールインフラストラクチャ。専用キュー、テンプレート、抑制リスト、およびダイジェストを使用します。

コンピューティング：
Kubernetesまたは同様のオーケストレーション上のステートレスサービス。キューラグ、CPU、および配信レイテンシに基づいてコンシューマーを水平に自動スケーリングします。ロードバランサーとサービスディスカバリを備えたリージョンデプロイメントを使用します。

ID：
ソート可能な通知IDにはUUIDv7、ULID、またはSnowflake IDを使用します。source_event_idと通知固有の冪等性キーによる冪等性を確保します。

スケーラビリティ戦略:

1. パーティショニング
   必要に応じて、ユーザーごとの順序付けのためにKafkaトピックを受信者_user_idでパーティション化します。受信者が不明なソースイベントの場合は、ファンアウトまでソースエンティティでパーティション化し、その後受信者で再パーティション化します。通知履歴をuser_idでパーティション化して、最新の通知クエリを最適化します。

2. 水平スケーリング
   すべてのパイプラインサービスは、ゲートウェイとストレージを除いてステートレスであるべきです。コンシューマーは、トピックパーティションとワーカーレプリカを増やすことでスケーリングできます。リアルタイムゲートウェイは、接続数と帯域幅でスケーリングします。

3. バックプレッシャー
   ダウンストリームプロバイダーが遅くなった場合、キューがスパイクを吸収します。チャネルと優先度ごとに別々のキューを使用するため、電子メールの遅延がダイレクトメッセージやアプリ内通知に影響を与えないようにします。ユーザーごと、アクターごと、通知タイプごと、プロバイダーごとにレート制限を適用します。

4. キャッシュ
   設定、デバイス・トークン、プレゼンス、テンプレート、および未読カウントをキャッシュします。頻繁に変更されるデータには短いTTLを使用します。キャッシュミスがすべての配信をブロックするべきではありません。設定が一時的に利用できない場合は、プロダクトルールに従って安全にフォールバックします。多くの場合、必須のアプリ内レコードのみを送信し、外部チャネルは延期します。

5. 集約
   いいねなどのインタラクションを集約して、ファンアウトとプッシュボリュームを削減します。例：分析のために各「いいね！」イベントを保存しますが、1つの投稿あたり1つの時間ウィンドウで1つの通知を送信します：「Alice、Bob、および他の10人があなたの投稿に「いいね！」をしました。」

6. ハイブリッドファンアウト
   高ファンアウトシナリオでは、数百万行をすぐに書き込むことを避けます。共有イベントを保存し、アクティブユーザー向けの通知を最初にマテリアライズし、その後アプリを開いたときに非アクティブユーザー向けに遅延してマテリアライズします。

7. マルチリージョンデプロイメント
   リージョン間でアクティブ-アクティブまたはアクティブ・パッシブでデプロイします。99.9%のアップタイムの場合、リアルタイムゲートウェイとステートレスサービスのアクティブ・アクティブが推奨されますが、データストアは最低限マルチAZレプリケーションを使用する必要があります。グローバルユーザールーティングは、ユーザーを最も近い正常なリージョンに送信できます。レプリケーションを備えたリージョナルKafkaクラスタまたはマネージドマルチリージョングリーミングシステムを使用します。

低レイテンシ戦略:

1. プロダクトサービスと通知配信を疎結合に保ちます。イベントの発行は高速かつ信頼性が高いべきです。
2. 十分なパーティションとコンシューマーを持つKafka/Pulsarを使用して、キューラグを低く保ちます。
3. プレゼンスルックアップとルーティング決定にはRedisを使用します。
4. オンラインユーザーにはWebSocket配信を使用します。これにより、サードパーティのプッシュプロバイダーのレイテンシを回避できます。
5. 信頼性の要件に応じて、配信の前または並行して通知レコードを永続化します。一般的なアプローチは、履歴を先に書き込み、次に配信することです。超低レイテンシの場合、配信とストレージは冪等な再試行と並行して発生する可能性があります。
6. 高価な同期結合を避けます。イベントにはレンダリングに必要な十分なメタデータを含めるか、キャッシュされたユーザー/オブジェクトの概要を使用します。
7. 低価値のソーシャル通知よりも、ダイレクトメッセージやセキュリティ上重要な通知を優先します。

信頼性と高可用性:

1. 耐久性のあるメッセージング
   Kafka/Pulsarのレプリケーションをアベイラビリティゾーン間で実施します。プロデューサーは確認応答と再試行を使用します。コンシューマーは、耐久性のある処理の後、または冪等な出力の書き込み後にのみオフセットをコミットします。

2. アウトボックスパターン
   ソースサービスは、ドメイン変更と送信イベントをトランザクション的にアウトボックステーブルに書き込みます。リレーがアウトボックスをKafkaに発行します。これにより、サービスがデータベース書き込みに成功しても、発行前に失敗した場合のイベント損失を防ぎます。

3. 冪等性
   すべてのステージは冪等である必要があります。再試行により、重複イベントが発生することが予想されます。source_event_id、notification_id、およびidempotency_keyを使用して、履歴レコードの重複や可能な限りプッシュ試行の重複を回避します。

4. 再試行ポリシー
   一時的な障害は、指数バックオフとジッターを備えた再試行トピックに送られます。無効なプッシュトークンなどの永続的な障害は、トークンを無効としてマークすることで処理されます。ポイズンメッセージは、検査のためにデッドレターキューに送られます。

5. グレースフルダウンサイジング
   メールプロバイダーがダウンしている場合は、メールをキューに入れ、アプリ内通知を続行します。プッシュプロバイダーが遅い場合は、WebSocket/アプリ内通知を配信し、後でプッシュを再試行します。設定キャッシュが利用できない場合は、耐久性のある設定読み取りまたは保守的なデフォルトにフォールバックします。プレゼンスが利用できない場合は、WebSocketをスキップし、プッシュ/履歴に依存します。

6. レプリケーションとバックアップ
   マルチAZデータベース、定期的なバックアップ、リレーショナルストアのポイントインタイムリカバリ、およびテスト済みの復元手順を使用します。Cassandra/ScyllaDBの場合、AZ間でレプリケーションファクター3を使用し、レイテンシ/信頼性のトレードオフに適したクォーラム設定を使用します。

7. モニタリングとSLO
   ソースイベント作成からクライアント受信までのp50/p95/p99のエンドツーエンドレイテンシを追跡します。キューラグ、配信失敗スパイク、プロバイダーのスロットリング、データベースのホットパーティション、WebSocket切断率、Redisメモリプレッシャー、およびコンシューマー再バランスストームについてアラートを発します。

通知履歴API:

最新の通知を取得 (GET):
クライアントは最新の100件の通知を要求します。APIゲートウェイはユーザーを認証し、通知APIはuser_idでcreated_atの降順で並べ替えたUserNotificationsをクエリし、不足している表示フィールドをキャッシュからエンリッチし、構造化されたレコードを返します。

通知を既読にする:
APIは、その通知のread_atを更新し、冪等に未読カウントを調整します。

すべて既読にする:
ユーザーのlast_read_timestampを保存し、オプションで古い未読レコードを非同期に更新します。これにより、大規模な同期書き込みを回避できます。

潜在的なボトルネックとトレードオフ:

1. ファンアウト爆発
   問題：一部のイベントは多数のユーザーに通知する可能性があり、キューとストレージを圧倒します。
   緩和策：ハイブリッドファンアウト、優先度付きキュー、集約、レート制限、および遅延マテリアライズ。
   トレードオフ：ファンアウトオンリードは書き込み負荷を軽減しますが、読み取りが複雑になり、読み取りレイテンシが増加する可能性があります。

2. ホットユーザーとホット投稿
   問題：有名人やバイラル投稿は、1人の受信者または1つのオブジェクトに対して大量の通知を生成する可能性があります。
   緩和策：オブジェクトと時間ウィンドウごとに通知を集約し、集約キーをシャーディングし、低価値の繰り返し通知を抑制します。
   トレードオフ：ユーザーはより粒度の低い通知を受け取る可能性があります。

3. プッシュプロバイダーの制限
   問題：APNs/FCM/電子メールプロバイダーはスロットリングまたは失敗する可能性があります。
   緩和策：専用プロバイダーワーカー、適応型レート制限、再試行、トークンクリーンアップ、およびプロバイダー固有のバックオフ。
   トレードオフ：外部プッシュ配信は、常に2秒未満のターゲットを満たすことはできません。オンラインユーザー向けのWebSocket配信は、信頼性の高い低レイテンシパスです。

4. データベース書き込み量
   問題：大規模なスケールでの受信者ごとの通知書き込みは高価になる可能性があります。
   緩和策：書き込み最適化されたワイドカラムストア、バッチ書き込み、TTL、集約、およびハイブリッドファンアウトを使用します。
   トレードオフ：ワイドカラムストアはクエリの柔軟性が限られています。設計はアクセスパターンに一致する必要があります。

5. 未読カウントの正確性
   問題：キャッシュされたカウンターは、再試行と同時読み取り更新の下でドリフトする可能性があります。
   緩和策：冪等更新、読み取りマーカー、定期的な調整。
   トレードオフ：正確な未読カウントは、結果整合性のある未読カウントよりも高価です。

6. 順序付け
   問題：分散処理により、通知が順不同で到着する可能性があります。
   緩和策：ソート可能なIDを使用し、読み取り時にイベント時間/通知IDで並べ替えます。必要に応じて、ユーザーごとのより強力な順序付けのために受信者でパーティション化します。
   トレードオフ：厳密なグローバル順序付けは実用的または必要ではありません。

7. レイテンシ対耐久性
   問題：配信前に履歴を書き込むと信頼性が向上しますが、レイテンシが増加します。
   緩和策：高速なローカルリージョンストレージを使用し、冪等性割り当て後にストレージ/配信を並列化します。
   トレードオフ：ストレージが遅延した場合、ストレージに表示される前にプッシュされた通知が一時的に表示される可能性があります。

8. 設定評価の複雑さ
   問題：イベントごとの設定チェックは、ピーク時に高価になる可能性があります。
   緩和策：設定をキャッシュし、有効な設定を事前計算し、設定変更時にキャッシュを無効化します。
   トレードオフ：設定変更は、強力な一貫性が必要ない限り、伝播に数秒かかる場合があります。

推奨される最終設計概要:

Kafka/Pulsarをバックボーンとするイベント駆動型アーキテクチャ、ステートレスな取り込み/ファンアウト/ルーティングサービス、ユーザーごとの通知履歴のためのCassandra/ScyllaDB/DynamoDB、プレゼンスとホットキャッシュのためのRedis、2秒未満のオンライン配信のためのWebSocketゲートウェイ、プラットフォーム通知のためのAPNs/FCM/Webプッシュ、および個別の電子メール配信パイプラインを使用します。システムは水平スケーリング可能で、主にuser_idでパーティション化され、耐久性のあるキューと冪等な処理を通じて回復力があり、キャッシュ、オンラインプレゼンスルーティング、優先度付きキュー、および集約を通じて低レイテンシに最適化されます。この設計は、機能要件を満たし、予想される1日あたり10億件のイベントとピーク時の5倍の負荷をサポートし、部分的な障害下でのグレースフルダウンサイジングを備えた99.9%の可用性への実用的なパスを提供します。