ソーシャルメディアアプリのリアルタイム通知システムの設計

リアルタイム通知システム設計（ソーシャルメディアアプリ向け）

1. 要件の再確認と概算

トラフィック見積もり：

• 1000万DAU × 1日あたり20件の通知 = 1日あたり2億件の通知
• 平均レート = 2億件 / 86,400秒 ≈ 2,315件/秒
• ピークレート（5倍） ≈ 11,500件/秒
• 1億DAU（将来）の場合：平均約23,000件/秒、ピーク約115,000件/秒

ストレージ見積もり：

• 各通知レコード約500バイト（メタデータ + ペイロード）
• 1日あたりのストレージ：2億件 × 500バイト = 100GB/日 → 約36TB/年（圧縮/アーカイブ前）
• 履歴要件（ユーザーあたり直近100件）は「ホット」な読み取り負荷の高いアクセスパターンであり、最近の通知を安価に取得できる設計（例：ユーザーごとの上限付きリスト）を優先し、完全な履歴はコールドストレージに保存する。

これにより、書き込み負荷が高く、ファンアウト負荷が高く、レイテンシに敏感で、取り込みと配信を分離する必要があるシステムであることが確認された。

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

[イベントプロデューサー] → [イベントバス / Kafka] → [通知サービス（コンシューマー）]
                                                    │
                        ┌───────────────────────────┼───────────────────────────┐
                        ▼                            ▼                           ▼
                 [設定サービス]         [レンダリング/テンプレート]     [レートリミッター/重複排除]
                        │                            │                           │
                        └───────────────┬────────────┴───────────────────────────┘
                                        ▼
                          [配信ディスパッチャー / ルーター]
                       ┌─────────────┬─────────────┬─────────────┐
                       ▼             ▼             ▼             ▼
                 [プッシュサービス]  [WebSocket/  [メールサービス]  [アプリ内ストア
                 （FCM/APNs）]     SSEゲートウェイ]   （SES/SendGrid）   書き込み - DynamoDB/Cassandra]
                       │             │
                  [モバイルデバイス][接続済みクライアント]

フロー：

1. ソースシステム（例：いいねサービス、コメントサービス、フォローサービス、メッセージングサービス）が、耐久性のあるメッセージバス（Kafka）にイベント（例：user_liked_post）を発行する。
2. 通知オーケストレーターがこれらのイベントを消費し、ユーザー設定を確認し、重複排除/レート制限/バッチ処理ロジック（例：「ジョンと他の5人があなたの投稿にいいねしました」）を適用して、通知オブジェクトを生成する。
3. オーケストレーターは通知を（履歴のために）永続化し、ユーザー設定とデバイス状態（オンラインかオフラインか）に基づいて適切なチャネルにファンアウトする配信ディスパッチャーにプッシュする。
4. 配信ワーカーが実際の送信を処理する：プッシュ通知プロバイダー（Android用FCM、iOS用APNs）、アプリ内リアルタイムバッジ更新用のWebSocket/SSE、トランザクションメールプロバイダー経由のメール。

3. 主要コンポーネント

3.1 イベント取り込みレイヤー — Apache Kafka

• すべてのソースサービスがKafkaトピックにイベントを発行する（ユーザーごとの順序性を保つためにuser_idでパーティション分割）。
• Kafkaは耐久性（レプリケーションファクター3）、高スループット、トラフィック急増時の自然なバッファリングを提供する。これはピークトラフィックが平均の5倍であることを考えると重要である。
• トピック：notification.likes, notification.comments, notification.followers, notification.messages（またはスキーマ進化のニーズに応じて、イベントタイプフィールドを持つ単一トピック）。

SQS/RabbitMQではなくKafkaを使用する理由？ Kafkaは、メッセージあたりのオーバーヘッドが少なく、非常に高いスループットを処理でき、リプレイ（失敗したバッチの再処理やバックフィルに便利）をサポートする。SQSは運用が簡単だが、10万メッセージ/秒以上に費用対効果よくスケールするのは難しく、コンシューマーグループのリプレイセマンティクスをそれほどクリーンにサポートしない。

3.2 通知オーケストレーターサービス

• Kafkaから読み取るステートレスコンシューマーグループ。
• 責任：
  • 設定確認：処理を続行する前に、ユーザーの通知設定を高速なキーバリューストア（RedisまたはDynamoDB）でクエリする。これにより、オプトアウトしている通知を生成する無駄な作業を回避できる。
  • 重複排除/バッチ処理：短命な集約ウィンドウ（例：TTL付きRedisソート済みセット）を使用して、類似イベントをバッチ処理する（例：60秒以内の同じ投稿への複数の「いいね」が1件の通知になる）。
  • フォロワー向けファンアウト：「フォローしている人からの新しい投稿」のようなイベントの場合、数百万人のフォロワーへのファンアウトが必要になる場合がある（有名人の問題）。ハイブリッドファンアウトモデルを使用する：
    • 通常ユーザー向けの書き込み時ファンアウト（各フォロワーの通知フィードに即座にプッシュ）。
    • 有名人/フォロワー数の多いアカウント向けの読み取り時ファンアウト（書き込みストームを回避するために読み取り時に計算）。
• 水平スケーラブル — Kafkaパーティション数とラグに基づいてコンシューマーインスタンスをスケーリングする。

3.3 通知ストア（永続化レイヤー）

• プライマリストア：Apache CassandraまたはDynamoDBのようなワイドカラムNoSQLデータベース。user_idでパーティション分割し、timestamp（降順）でクラスタリング/ソートする。
  • このモデルは、主要なアクセスパターンが「ユーザーXの直近100件の通知を取得する」であり、これはパーティションに対する単純な範囲クエリであり、結合は不要なため理想的である。
  • Cassandraは、調整可能な一貫性と、1億ユーザーをはるかに超える水平スケーラビリティを提供する。DynamoDBは、運用オーバーヘッドが少ないフルマネージドの代替手段を提供する（トレードオフ：非常に大規模な場合、コストが高くなる可能性があり、極端にアクティブなユーザーの場合はパーティションキーにソルトを付けないとホットパーティションのリスクがある）。
• TTL/アーカイブ：ホットストアには最近の通知（例：30〜90日）のみを保持する。古いデータは、コンプライアンス/監査のために安価なストレージ（S3 + Glacier）にアーカイブし、「直近100件」の上限は書き込み時に強制する（ユーザーごとの上限付きリスト、または定期的なコンパクションでトリミング）。

3.4 配信ディスパッチャー

• 最終的な通知オブジェクトを読み取り、以下に基づいて使用するチャネルを決定する：
  • ユーザーのチャネル設定（プッシュ/メール/両方/なし）
  • ユーザーのオンライン状態（Redisをバックエンドとするプレゼンスサービスによって追跡され、WebSocket/ハートビートによって更新される）
• 以下にルーティングする：
  • プッシュ通知サービス：FCM（Android）とAPNs（iOS）と統合する。リトライ、ペイロード形式、デバイスートークン管理（トークンはuser_devicesテーブルに保存され、アプリ起動時に更新される）を正規化するために、内部抽象化レイヤーにラップする。
  • アプリ内リアルタイム配信：WebSocket/SSE経由でアクティブに接続しているユーザー向けに、接続ゲートウェイ（例：ロードバランサーの後ろにあるWebSocketサーバー群、Socket.IOやAWS API Gateway WebSocketsのようなマネージドサービスを使用）に直接プッシュする。接続とサーバーのマッピングはRedisで追跡されるため、どのディスパッチャーノードもユーザーの接続を保持しているゲートウェイインスタンスを見つけることができる。
  • メールサービス：あまり時間的制約のない通知（例：週次ダイジェスト）や、特定の通知タイプでオフラインユーザーのフォールバックとして、Amazon SESやSendGridのようなプロバイダーと統合し、メールSLAはより緩和されているため（数秒から数分で十分）、別の優先度の低いキューを使用する。

3.5 設定サービス

• リレーショナルDB（Postgres）またはDynamoDBをバックエンドとするシンプルなサービス。Redisに積極的にキャッシュする（設定は頻繁には変更されず、読み取りは非常に頻繁に行われるため、キャッシュに最適な候補）。
• スキーマ：user_id, notification_type, channel, enabled。

4. データモデル

通知テーブル（Cassandra/DynamoDB）

パーティションキー：user_id
クラスタリングキー：notification_id（時間ベースのUUID、降順ソート）
属性：
  - type（like, comment, follow, message）
  - actor_id（トリガーしたユーザーID）
  - actor_ids（配列、バッチ通知用）
  - target_object_id（post_id, comment_idなど）
  - message_preview
  - created_at
  - read_status（ブール値）
  - delivered_channels（配列：push, email, in-app）

ユーザー設定テーブル

パーティションキー：user_id
属性：{ likes: {push: true, email: false}, comments: {...}, follows: {...}, messages: {...} }

デバイスートークンテーブル

パーティションキー：user_id
クラスタリングキー：device_id
属性：platform（ios/android）、token、last_active

5. 信頼性の確保（「通知を失わない」）

1. 耐久性のあるメッセージング：レプリケーションファクター≥3のKafkaと、プロデューサーでのacks=allにより、処理前にイベントが失われないことが保証される。
2. 少なくとも1回の処理と冪等性：コンシューマーは障害/再起動時に再処理する可能性があるため、通知IDは冪等書き込みを可能にするために決定論的に生成される（例：ソースイベントID + タイプのハッシュ）。これにより、リトライ時の重複通知を防ぐ。
3. デッドレターキュー（DLQ）：配信失敗（例：プッシュプロバイダーのタイムアウト）は、指数バックオフリトライ（例：ジッター付き3回リトライ）の後、DLQトピックに送られ、それでも失敗した場合は手動/アラートレビューに送られる。
4. 配信試行の前に通知をストアに書き込む：これにより、「通知が存在する」（耐久性/履歴）と「通知が配信された」（ベストエフォートリアルタイム）が分離される。プッシュ配信が失敗した場合でも、ユーザーは次回アプリを開いて通知APIをポーリングしたときに通知を確認できる。
5. ソースサービスでのアウトボクシングパターン：二重書き込み問題（DB書き込み + イベント発行）を回避するために、トランザクションアウトボクシングパターンを使用する。これにより、ソースサービスのDBに「いいね」が記録されると、Debeziumのようなチェンジデータキャプチャ（CDC）ツールを介して、イベントが確実にKafkaにも発行される。

6. スケーラビリティ戦略（1000万 → 1億DAU）

• Kafka：パーティション数を増やす（ユーザーIDハッシュでパーティション分割） — ブローカー/コンシューマーが増えるにつれて線形にスケールする。
• 通知オーケストレーターとディスパッチャー：ステートレスで、コンシューマーグループの後ろで水平スケーラブル。Kafkaコンシューマーラグに基づいてKubernetes HPAでスケールする。
• Cassandra：リングにノードを追加する — 整合性ハッシュが負荷を自動的に分散する。バイラルコンテンツ/有名人アカウントからのホットパーティションに注意する — バケット化によって軽減する（例：有名人のファンアウトを複数のシャードキーに分割する）。
• WebSocketゲートウェイ：水平スケーリングする。Redisの接続レジストリを使用したスティッキーセッションを利用して、ディスパッチャーがどのゲートウェイノードがどの接続を所有しているかを、ゲートウェイノードの数に関係なく把握できるようにする。
• プッシュ/メールプロバイダー：これらはサードパーティのマネージドサービス（FCM、APNs、SES）であり、独立してスケールする。私たちの責任は、プロバイダーのクォータ内に収まるようにバッチ処理とレート制限を行うことである。
• キャッシング：設定とプレゼンスデータの積極的なRedisキャッシングは、ユーザー数が10倍に増加してもDB負荷を軽減する。

7. 主要なトレードオフ

| 決定 | トレードオフ |
|---|---|
| Kafka vs. よりシンプルなキュー（SQS） | Kafkaは運用上の複雑さを増す（専用の運用専門知識、ZooKeeper/KRaft管理が必要）が、この規模で必要なはるかに優れたスループットとリプレイ機能を提供する。 |
| Cassandra vs. DynamoDB | Cassandraは、非常に大規模な場合に、より多くの制御と潜在的に低いコストを提供するが、社内運用が必要。DynamoDBはフルマネージド（構築が速く、運用負荷が少ない）だが、極端な規模では高価になる可能性があり、アイテムサイズ/スループットパーティショニングの制約がより厳しい。 |
| 書き込み時ファンアウト vs. 読み取り時ファンアウト | 書き込み時のファンアウトは、読み取りレイテンシを低くする（2秒SLAに最適）が、有名人の場合に「鳴り響くような」書き込みストームのリスクがある。読み取り時のファンアウトはそれを回避するが、読み取り時のレイテンシと計算が増加する。ハイブリッドアプローチは両方をバランスさせるが、設計/コードの複雑さ（2つのコードパス）が増す。 |
| 完全な履歴の保存 vs. 上限100件のホット + アーカイブ | ホットストレージコストを削減し、クエリを高速に保つが、コンプライアンスや「さらに読み込む」機能のためにアーカイブ/取得パスが必要になり、複雑さが増す。 |
| 少なくとも1回の配信 + 冪等性 vs. 厳密に1回 | 分散システムにおける厳密に1回のセマンティクスは、コストが高く複雑である（トランザクションコンシューマーが必要）。少なくとも1回 + 冪等書き込みは、はるかに低い運用コストで同じ実用的な保証（表示される重複通知なし）を達成する。 |
| すべてに対するリアルタイムプッシュ vs. バッチ処理/集約 | 類似通知の集約（例：「10人があなたの写真にいいねしました」）は、通知疲れと配信量を削減し、UXとコストの両方を改善する。ただし、より複雑なオーケストレーションロジックとわずかなバッファリング遅延が発生する（ウィンドウが短い場合、例えば最大保持時間5〜10秒でフラッシュされるため、依然として2秒SLA内に収まる）。 |

8. モニタリングとアラート

• Kafkaコンシューマーラグ、チャネルごとの配信成功/失敗率、P50/P95/P99のエンドツーエンドレイテンシ（イベント取り込み → デバイス配信）、およびDLQの深さを追跡する。
• SLAダッシュボードは、P95レイテンシが2秒を超えた場合やDLQの増加がシステム的な配信障害（例：FCM障害）を示唆する場合にオンコール担当者にアラートを出し、自動フェイルオーバーロジック（例：キュー保持とバックオフ付きリトライ、ドロップするのではなく）をトリガーする。

まとめ

この設計は、通知の生成（イベント駆動型、Kafkaベース、冪等）と配信（チャネルごとのリトライ/バックオフを備えたマルチチャネルディスパッチャー）を分離し、ユーザーごとの最近の履歴アクセスパターンに最適化されたワイドカラムストアによってバックアップされている。この分離により、システムはデータ損失を保証しながら2秒のレイテンシSLAを満たすことができ、また、取り込み、処理、ストレージ、配信のすべてのレイヤーで水平スケーリングが可能であり、管理可能な運用およびコストオーバーヘッドで10倍の将来の成長をサポートできる。

概要

システムは、すべての通知を永続的で受信者固有のレコードとして扱い、1つ以上のチャネルを通じて非同期に配信する必要があります。永続的なアプリ内受信トレイが信頼できる情報源であり、モバイルプッシュとEメールは、そのレコードから派生した配信試行です。この分離により、APNs、FCM、またはEメールサービスなどの外部プロバイダーを待たずに、低レイテンシを実現できます。

容量見積もり

DAUが1,000万で、ユーザーあたりの通知が1日20件の場合、システムは1日あたり約2億件の通知を作成します。これは、平均で毎秒約2,315件、指定されたピーク時の5倍で毎秒11,600件に相当します。DAUが1億の場合、対応するレートは平均で約23,000件/秒、ピークで116,000件/秒になります。

これらは受信者あたりの通知レートであり、単なるソースイベントレートではありません。有名人の投稿は、ホットキーまたはファンアウトスパイクを生成する可能性があるため、取り込みレイヤーとキューイングレイヤーは、計算されたピークを上回るようにプロビジョニングする必要があります。当初は毎秒約25,000件の通知、最終的には毎秒少なくとも200,000件の通知に対応できるようにします。ペイロードは小さく保ち、メディアと完全な投稿コンテンツは、埋め込むのではなくIDで参照するようにします。

高レベルアーキテクチャ

いいね、コメント、フォロー、ダイレクトメッセージなどのソーシャルサービスは、自身の状態と通知イベントを、同じデータベーストランザクション内でトランザクションアウトボックスに書き込みます。アウトボックスパブリッシャーは、これらのイベントをApache Kafkaなどの永続的なイベントログに継続的に転送します。これにより、ソーシャルアクションは成功したが通知イベントが失われたというデュアルライト障害を回避できます。

通知プロセッサは、ソースイベントを消費し、検証し、受信者を特定し、決定論的な通知IDを生成し、通知設定をロードし、軽量なエンリッチメントを実行し、受信者通知を受信トレイストアに書き込みます。その後、チャネル固有のKafkaトピックに、有効化されたチャネルごとに1つの永続的な配信コマンドを発行します。

モバイルプッシュワーカーはプッシュコマンドを消費し、APNsまたはFCMを呼び出します。Eメールワーカーはテンプレートをレンダリングし、Amazon SES、SendGrid、または内部メール転送サービスなどのプロバイダーを呼び出します。WebSocketゲートウェイもアプリ内配信コマンドを消費し、現在接続中のクライアントを即座に更新できます。切断されたクライアントは、再接続時に永続的な受信トレイを引き続き表示します。配信結果と再試行は非同期に記録されます。

メインフローは次のとおりです。

ソーシャルサービスとトランザクションアウトボックス → Kafkaソースイベントトピック → 通知プロセッサ → 永続受信トレイストア → チャネルコマンドトピック → WebSocket、APNs/FCM、およびEメールワーカー。

読み取りフローは次のとおりです。

クライアント → APIゲートウェイ → 通知API → 受信トレイストアと設定ストア。

コアコンポーネント

APIゲートウェイは、認証、レート制限、リクエストルーティング、および不正行為保護を処理します。通知APIは、最近の通知の取得、カーソルベースのページネーション、未読カウント、1つ以上のアイテムの既読マーク、および設定の管理をサポートします。

Kafkaは、永続的なバッファリング、トラフィック平滑化、リプレイ、コンシューマー分離、および水平スケーラビリティを提供します。トピックは少なくとも3つのアベイラビリティゾーンにレプリケートされます。ソーストピックは、受信者展開後に受信者ユーザーIDでパーティション分割でき、ユーザーごとの順序を維持しながらユーザーをパーティションに分散させます。高ファンアウト展開では、個別のワーカープールを使用できるため、1つの大きなイベントが通常のトラフィックをブロックすることはありません。

通知プロセッサはステートレスであり、キューラグ、処理レイテンシ、CPU、およびスループットを使用して自動スケーリングされるべきです。チャネルコマンドを発行する前に設定評価を実行します。設定はRedisにキャッシュできますが、権威ある値は永続ストアに残ります。設定が変更されるたびにキャッシュ無効化イベントが発行されます。

受信トレイストアは、DynamoDB、Cassandra、またはScyllaDBなどの水平スケーラブルなキーバリューストアまたはワイドカラムストアであるべきです。DynamoDBは運用上の負担が少なく、マネージドなマルチリージョンオプションを提供します。CassandraまたはScyllaDBは、持続的な大規模スケールではより安価になる可能性がありますが、より多くの運用知識が必要です。リレーショナルデータベースは、書き込み量、パーティションの成長、およびクロスシャードスケーリングが高価になるため、プライマリ受信トレイにはあまり適していません。

Redisは未読カウントと受信トレイの最初のページをキャッシュする場合がありますが、システムの記録であってはなりません。WebSocketゲートウェイは、アクティブな接続状態を除いてステートレスです。Redisまたは同様のエフェメラルストアのプレゼンスディレクトリは、ユーザーをゲートウェイインスタンスにマッピングします。

データモデル

通知レコードには、notification_id、recipient_user_id、type、actor_user_id、object_type、object_id、creation_time、template_version、コンパクトレンダリングデータ、read_time、およびオプションのグループ化情報が含まれます。チャネル状態には、要求されたチャネルと、保留中、ディスパッチ済み、失敗、または抑制済みなどの配信ステータスが含まれるべきです。大きな本文や変更可能なソーシャルコンテンツは、不変のスナップショットが必要ない限り、レコードにコピーされるべきではありません。

適切な受信トレイキーは、partition_key = recipient_user_id にオプションの時間バケットを追加したもので、sort_key = reverse_timestamp に notification_id を追加したものです。逆時系列ソートにより、最新ページが効率的になります。通常のボリュームでは、ユーザーあたりの1つのパーティションで十分です。例外的にアクティブなアカウントは、月次バケットを使用できます。APIは最も新しいバケットを最初にクエリし、不透明なカーソルを古いバケットにたどります。

要件では、最後の100件の通知のみが公開されます。サービスは、TTL（有効期限）を適用しながら、それよりも多い（たとえば30日から90日）を保持できます。読み取りAPIは最大100件を返します。レコードの非同期トリミングまたは期限切れは、挿入ごとに同期削除を実行するよりも安全で安価です。厳密に100件のレコードのみを物理的に保存する必要がある場合は、バックグラウンドコンパクターが古いエントリを削除できます。

設定はユーザーIDをキーとし、タイプごと、チャネルごとの設定（例：likes.push、likes.email、comments.push、comments.email）、およびグローバルミュート、ロケール、タイムゾーン、単調増加するバージョンを含みます。デバイストークンは、ユーザーIDとデバイスIDごとに別々に保存され、プラットフォーム、トークン、最終確認時刻、および有効性ステータスが含まれます。トークンは暗号化され、永続的なAPNsまたはFCMエラーの後に無効化されるべきです。

決定論的な通知IDは、source_event_id、recipient_user_id、通知タイプ、およびセマンティックバージョンから派生できます。受信トレイへの書き込みは、そのIDを条件としており、リプレイと重複消費を安全にします。配信コマンドは、通知IDとチャネルに基づいた同様の決定論的なIDを持ちます。

配信セマンティクスと信頼性

実際的な保証は、永続的なアット least-once処理であり、冪等な効果を持ちます。データベース、Kafka、APNs、FCM、およびEメール全体でのExactly-once配信は、エンドツーエンドでは達成できません。トランザクションアウトボックスは、受け入れられたソースアクションが最終的に公開されることを保証します。Kafkaのレプリケーションと確認済みの書き込みは、キューの損失を防ぎます。条件付き受信トレイ書き込みは、重複レコードを抑制します。チャネルワーカーは、配信試行IDを保存またはその他の方法で重複排除し、再試行中の重複送信を減らします。

通知は、そのアウトボックス行を含むソーストランザクションがコミットされた後にのみ受け入れられたと見なされます。永続的な作成済みと見なされるのは、受信トレイへの書き込みが成功した後です。Kafkaオフセットは、対応する永続書き込みまたはプロバイダーへの引き渡しが完了した後のみコミットされます。一時的な障害には、指数バックオフとジッターが使用されます。制限された回数の試行の後、コマンドはエラー、ペイロード参照、および再試行履歴とともにデッドレタートピックに移動します。オペレーターは、修正後にこのトピックをリプレイできます。

モバイルプロバイダーとEメールインフラストラクチャは、デバイスまたはメールボックスが2秒以内に通知を表示することを保証できません。したがって、サービスは、コミットされたソースイベントから永続的な受信トレイの可視性と最初のプロバイダーディスパッチまでのレイテンシ目標を定義する必要があります。妥当なSLOは、サポートされている負荷の下で2秒未満で99パーセントです。APNsおよびFCMの確認は、プロバイダーの受け入れを意味し、ユーザーの表示を意味するものではありません。永続的な受信トレイは、プロバイダーの障害やオフラインデバイスがユーザーの履歴から通知を失わないことを保証します。

現在接続中のクライアントの場合、WebSocketパスは通常、最も速い配信を提供します。WebSocketメッセージは通知IDを運び、クライアントはそれらを受信トレイレコードに対して重複排除します。再接続時に、クライアントは最後のカーソル以降の通知を取得するため、ソケットメッセージのドロップはギャップを作成しません。

スケーラビリティ

Kafkaトピックは、期待される並列処理のために十分なパーティション数で開始し、パーティションのスループット制限に達する前に拡張する必要があります。受信者IDパーティション分割は、通常のユーザーを均等に分散させます。有名人のイベントは、ホットパーティションを作成するため、アクターIDをパーティションキーとして使用すべきではありません。受信者展開は、大規模なオーディエンスをチャンクに分割し、各チャンクを個別に公開できます。

プロセッサ、WebSocketゲートウェイ、およびチャネルワーカーはステートレスであり、水平スケーラブルです。自動スケーリングは、CPUだけでなく、Kafkaのラグと最も古いメッセージの年齢を考慮する必要があります。個別のコンシューマーグループとクォータは、低優先度のいいねやEメールからダイレクトメッセージを分離します。過負荷時には、ダイレクトメッセージとコメントの容量が予約され、Eメールと低優先度のいいねは破棄されずにキューイングできます。

受信トレイの容量はユーザーとともに線形に増加しますが、TTLと限定履歴の要件によって制限されます。DAUが1億で1日あたりの通知が20件の場合、設計では約20億件の毎日の書き込みを処理する必要があります。時間バケット化されたユーザーパーティション、オンデマンドまたはプロビジョニングされたデータベース容量、圧縮されたコンパクトレコード、および同期的なセカンダリインデックスのファンアウトなしにより、これを管理可能に保ちます。高価なグローバルクエリは、トランザクション受信トレイではなく、分析パイプラインから提供されるべきです。

高可用性と災害復旧

すべての同期コンポーネントは、ヘルスチェックされたロードバランサーの後ろで、少なくとも3つのアベイラビリティゾーンで実行されます。Kafkaは、強力な確認設定と適切な最小同期レプリカ数を持つレプリケーションファクター3を使用します。受信トレイと設定ストアは、マルチゾーンレプリケーションとポイントインタイムバックアップを使用します。デプロイメントは、カナリアまたはローリング戦略、後方互換性のあるイベントスキーマ、およびレジストリを介したスキーマバージョン管理を使用します。

費用対効果の高い初期設計は、マルチゾーン冗長性を持つ1つのアクティブリージョンと、非同期にレプリケートされたウォームスタンバイリージョンを使用します。復旧手順では、スタンバイを昇格させ、レプリケートされたオフセットまたは保持されたイベントからコンシューマーを復元し、処理が冪等であるため安全にリプレイします。より厳密なリージョン可用性のために、システムはアクティブ-アクティブなリージョン取り込みに進化でき、ユーザーはホームリージョンとグローバルに一意なイベントIDに割り当てられます。アクティブ-アクティブは回復時間を改善しますが、データベースコスト、重複処理、順序付けの複雑さ、および設定の一貫性の課題が増加します。

設定の変更は、ユーザーのホームリージョンで強力に一貫した書き込みを使用する必要があります。設定変更前に既に永続的に作成された通知は、引き続き配信される可能性があります。この境界は文書化されるべきです。法的に必要な抑制またはアカウント削除の場合、ワーカーは外部配信の直前に、追加の権威あるチェックを実行する必要があります。

レイテンシ最適化

クリティカルパスには、APNs、FCM、またはEメールプロバイダーへの同期呼び出しは含まれません。イベントペイロードには、基本的なレンダリングに必要なアクターとオブジェクトのメタデータが含まれており、複数のダウンストリームサービス呼び出しを回避します。オプションのエンリッチメントが不足している場合でも、汎用通知を生成し、配信をブロックしないようにします。設定レコードとテンプレートはローカルまたはRedisにキャッシュされ、Kafka、データベース、およびプロバイダーへの接続はプールされます。

Eメールのレンダリングとディスパッチは、Eメールがアプリ内配信よりも遅く高価であるため、別のトピックを使用します。製品要件で許可される場合、緊急でない「いいね」はグループ化されたり、ダイジェストEメールとして送信されたりする場合がありますが、コメント、フォロー、ダイレクトメッセージは即時配信のままです。グループ化はコストとユーザーの疲労を削減しますが、通知のセマンティクスを変更するため、明示的な製品決定が必要です。

API設計

GET /v1/notifications?cursor=...&limit=... は、最新の100件に制限された逆時系列レコードを返します。POST /v1/notifications/read は、1つ以上の通知IDまたは読み取りタイムスタンプを受け入れます。GETおよびPUT /v1/notification-preferences は、バージョン管理された設定を読み取り、更新します。POSTおよびDELETE device-token エンドポイントは、デバイスを登録および取り消します。すべてのミューテーションエンドポイントは、冪等性キーをサポートします。

未読カウントは、受信トレイと既読イベントから更新される、最終的に一貫したカウンターとして維持できます。再試行は単純なインクリメントを破損する可能性があるため、カウンターの更新は冪等であるか、定期的に権威あるレコードから調整される必要があります。正確な未読カウントが必要な場合、サービスは、より高い読み取りおよびストレージコストで、ユーザー範囲の未読インデックスをクエリできます。

オブザーバビリティと運用

メトリクスには、イベント受付率、通知タイプとチャネルごとのエンドツーエンドレイテンシ、Kafkaラグ、最も古いキューイングコマンド、受信トレイ書き込みエラー、プロバイダー応答コード、再試行回数、デッドレターボリューム、WebSocket接続数、設定キャッシュヒット率、および重複抑制率が含まれます。分散トレーシングは、すべてのステージでsource_event_idとnotification_idを伝播させます。構造化ログは、メッセージ本文と機密トークンを除外します。

アラートは、SLOのバーンレートと最も古いメッセージの年齢に基づいて行う必要があります。合成ユーザーは継続的にイベントを生成し、受信トレイ、WebSocket、プッシュプロバイダー、およびEメールプロバイダーのパスを検証します。デッドレターリプレイ、リージョンフェイルオーバー、プロバイダー障害、Kafkaパーティション損失、およびデータベーススロットリングは、ランブックとフォールトインジェクションテストを通じて定期的に実行する必要があります。

セキュリティとプライバシー

サービスは、短期的なIDで認証し、最小権限のアクセスを受け取ります。データは転送中および保存中に暗号化され、デバイストークンとEメールアドレスは追加の保護を受けます。ロック画面に表示される通知ペイロードは、ユーザーがプレビューを明示的に有効にしない限り、機密性の高いダイレクトメッセージコンテンツを避けるべきです。APIは、ユーザーが自身の受信トレイと設定にのみアクセスできることを強制します。保持期間、アカウント削除、監査ログ、およびリージョンデータレジデンシーの要件は、ストレージライフサイクルに組み込む必要があります。

コストとトレードオフ

Kafkaは、バーストを吸収しリプレイを可能にするため、同期サービス間通信よりも好ましいですが、運用上の複雑さと最終的な一貫性を導入します。マネージドKafkaサービスは、より高い直接コストで運用リスクを軽減します。DynamoDBは運用が簡単で弾力性がありますが、CassandraまたはScyllaDBは、持続的なストレージコストを削減する可能性がありますが、有能な運用チームが必要です。

チャネルコマンドを発行する前に受信トレイに書き込むことで、履歴が権威あるものになり、どのチャネルコマンドも欠落したレコードを参照しないようになりますが、わずかな追加の書き込みレイテンシが発生します。決定論的なIDと冪等性と組み合わせると、クラッシュや外部プロバイダーの再試行を通じて正しい状態を維持できるため、アット least-once配信が、いわゆるexactly-once設計よりも選択されます。

受信者キーパーティション分割は、ユーザーごとの順序を維持しますが、グローバルな順序は提供しません。これは不要です。すべての通知にわたる厳密な順序付けは、スループットと可用性を低下させます。同様に、設定キャッシュはレイテンシを改善しますが、一時的に古い値を返す可能性があります。バージョン管理された無効化と機密性の高い抑制のための最終チェックは、パフォーマンスと正確性のバランスを取ります。

推奨される初期デプロイメントは、マネージドKafkaクラスター、マネージドDynamoDBスタイルの受信トレイおよび設定ストレージ、エフェメラルキャッシュおよびプレゼンス用のRedis、Kubernetesまたはマネージドコンテナプラットフォーム上のステートレスコンテナ化サービス、モバイルプッシュ用のAPNs/FCM、およびSESまたは同等のEメールプロバイダーです。このアーキテクチャは、現在のピークを快適にサポートし、DAU1億に向けて水平方向にスケーリングし、永続的なユーザー可視の履歴を保持し、外部配信障害をコアソーシャルアプリケーションから分離します。