リアルタイムEコマース通知システムの設計

概要 疎結合されたマイクロサービスとマネージドクラウドサービスで構築された、水平スケーラブルなストリーミングファーストの通知プラットフォームを提案します。主なアイデアは、取り込みと再生のための耐久性のあるイベントログ（Kafka/Kinesis/Pub/Sub）の使用、イベントのエンリッチメントとパーソナライゼーションのためのストリームプロセッサ、少なくとも1回の配信保証のための配信状態の永続化とリトライを行う配信パイプライン、そしてプッシュ（APNs/FCM）およびリアルタイムWeb（WebSocket）のためのデバイス固有のコネクタです。この設計は、100k通知/分（≈1.7k/秒）のピークに対応し、メッセージの99%で5秒未満の配信を目標とし、パーソナライゼーションと信頼性の高い配信をサポートします。 高レベルアーキテクチャ（コンポーネントと相互作用） 1) イベントプロデューサー - ソース：注文サービス（注文更新）、価格設定サービス（価格変更）、マーケティング/CRM（フラッシュセール）。各サービスは、関連する変更が発生するたびに、取り込みレイヤーに軽量イベントを発行します。イベントには、event_id、event_type、payload、timestamp、およびメタデータ（user_idsまたはproduct_ids）が含まれます。 2) 取り込み / 耐久性のあるイベントログ - マネージドパーティションログ：Apache Kafka（セルフマネージドまたはConfluent Cloud）またはクラウド同等物（AWS Kinesis Data Streams、GCP Pub/Sub）。プロデューサーは、イベントタイプとパーティションキー（user_idまたはproduct_id）で編成されたトピックにイベントを発行し、必要な場合（例：注文ごとの注文更新）に順序を保持します。 - 耐久性のあるログを使用する理由：再生可能性、リトライのための保持、バックプレッシャーの平滑化を提供します。 3) ストリーム処理 / エンリッチメントレイヤー - ステートレス/ステートフルストリームプロセッサ（Apache Flink、Kafka Streams、またはマネージドDataflow）は、イベントトピックをサブスクライブして、イベントの検証、ユーザープロファイルと設定でのエンリッチメント、製品/セグメントデータとの結合、通知の適格性と優先度の決定（例：重要な注文更新対マーケティング）を行います。 - 出力：正規化された通知タスク（task_id、user_id(s)、payload、type、priority、ttl、dedup_key）を通知タスクトピックに発行します。 4) パーソナライゼーションとセグメンテーション - パーソナライゼーションルールは、特徴量ストア/プロファイルDB（DynamoDB/Cassandra/Postgres + ホットリードのためのRedisキャッシュ）とルールエンジンまたはMLモデルを組み合わせたサービスに存在します。ストリームプロセッサは、このサービスを呼び出すか、ローカルキャッシュされたルックアップを使用して、ターゲット受信者とコンテンツバリアントを決定します。 - セグメントへの広範なセグメンテーションイベント（フラッシュセール）の場合、高速ストア（Redis、Druid、またはBigQuery/ElastiCacheルックアップ）に保存された事前計算済みセグメントを使用して、ユーザーリストに展開するか、ストリーミングジョブ内でフィルターロジックを適用します。 5) 配信オーケストレーション / ファンアウト - 配信オーケストレータサービスは、通知タスクトピックをサブスクライブし、デバイス登録、スロットリングルール、ファンアウト戦略を評価します。単一ユーザー通知（注文更新）の場合は、デバイスごとに配信ジョブを作成します。セグメントベースのブロードキャストの場合は、パーティション化されたキューを介して多数の配信ジョブにファンアウトします。 - 配信ジョブは、永続的なシャードごとの配信キュー（Kafkaトピック、Redis Streams、または順序が必要な場合はFIFO付きSQS）に配置されます。ジョブには、リトライカウンターと冪等性/重複排除キーが含まれます。 6) 配信ワーカー / コネクタ - キューラグによって自動スケーリングされるステートレスワーカーフリート。各ワーカーはジョブを取得し、デバイスチャネルに適したコネクタを介して配信を試みます。 - モバイルプッシュ：デバイス登録簿に保存されているデバイストークンを使用したFCM（Android）およびAPNs（iOS）。 - Web/ブラウザ：Webプッシュ（VAPID）または永続WebSocket接続（AWS API Gateway WebSocketのようなマネージド接続サービスまたはELBの背後にあるセルフマネージドソケットクラスターを介して管理）。 - フォールバックチャネル：重要な未配信通知のための電子メール（SES/SendGrid）またはSMS（Twilio）。 - ワーカーは、配信ステータスストアに配信試行（成功/失敗）を永続化し、監視とさらなるリトライのために完了またはリトライイベントをログに発行します。 7) デバイス登録簿とユーザー設定 - user_id -> デバイス（トークン、プラットフォーム、最終確認日時、設定、オプトインフラグ）の耐久性のあるストア。高スループット書き込みにはDynamoDB/Cassandraを使用します。低レイテンシ読み込みのためにアクティブなデバイスをRedisにキャッシュします。 8) 配信状態と再生可能性 - すべての通知タスクと配信試行は、耐久性のあるストア（Kafka + S3へのアーカイブ）と配信ステータスDBにログ記録されます。これにより、少なくとも1回の配信、監査、および調整が可能になります。未確認/失敗した配信は、指数関数的バックオフを使用してリトライオーケストレータによってリトライされます。 9) モニタリング、オブザーバビリティ、およびSLA強制 - メトリクス：取り込みレート、処理レイテンシ、キューラグ、配信成功率。パスレベルレイテンシ（OpenTelemetry）のトレース、およびSLA違反のアラート。99パーセンタイルレイテンシとチャネルごとの失敗率を監視するためのダッシュボード。 主要な設計上の選択と正当化 - 耐久性のあるログ（Kafka/Kinesis/PubSub）：少なくとも1回のセマンティクスとデバッグに不可欠な高スループットと再生可能性を提供します。user_id/product_idによるパーティショニングは、エンティティごとの順序を保持します（注文更新に重要）。マネージドクラウドストリーミングは運用オーバーヘッドを削減します。 - ストリーム処理（Flink/Kafka Streams/Dataflow）：取り込みに近い場所でのサブ秒エンリッチメントとセグメンテーションを可能にします。ステートフルストリーミングは、低レイテンシでウィンドウ結合（例：価格下落イベントをウィッシュリストに一致させる）をサポートします。 - NoSQL + キャッシュのデバイス登録簿：DynamoDB/Cassandraは、数千万ユーザーに対して水平スケーリングします。Redisは、低レイテンシの決定のためのホットパスルックアップを処理します。 - 配信キューと自動スケーリングワーカー：重いファンアウトをアップストリーム処理から分離し、フラッシュセール中のスムーズなスケーリングを可能にしながら、ダウンストリームプッシュプロバイダーのレート制限を制御します。 - プッシュコネクタ（APNs/FCM）+ WebSocket：プッシュサービスはクライアントポーリングを最小限に抑え、低レイテンシを実現します。WebSocketは、リアルタイムのアプリ内/Web配信に使用されます。WebSocketが利用できない場合は、プッシュまたはプルにフォールバックします。 - 少なくとも1回、冪等性、および重複排除：タスクレベルのdedup_keyを保存し、クライアント側で配信を冪等にするか、可能な場合はSDK確認を使用します。サーバー側では、ユーザーに表示される通知を作成する前に、task_id/dedup_keyで重複排除します。 要件の充足 - 高スループット：パーティション化されたログと自動スケーリングワーカーは水平スケーリングをサポートします。Kafka/Kinesisは、複数のパーティションで毎秒数百万イベントを処理できます。100k/分はこれらのシステムとしては控えめであり、アーキテクチャはパーティションとワーカーを追加することで、はるかに高いボリュームにスケールできます。 - 低レイテンシ：ストリーミングエンリッチメントと直接プッシュ/WebSocketコネクタは低レイテンシパスです。99パーセンタイルを5秒未満にターゲットにする：処理パイプラインを1〜2秒未満に保ち（ストリーミングジョブ）、自動スケーリングワーカーで配信キューラグを低く保ち、ホットパスでのDBルックアップを回避するためにデバイスキャッシュを使用します。 - 信頼性：耐久性のあるイベントログ+永続化された配信状態+リトライオーケストレータにより、少なくとも1回の配信が保証されます。重要な通知（注文更新）については、より強力な保証を有効にします：ダウンストリームサービスからの同期確認と、確認済み配信レシート（例：デバイス確認またはフォールバックチャネル確認）の保存。指数関数的バックオフとエスカレーションを代替チャネルに適用します。 - スケーラビリティ：すべてのステートフルコンポーネントは水平スケーリング可能なストア（Kafka、DynamoDB/Cassandra、Redisクラスター）を使用します。ワーカーとストリーマーは自動スケーリングされるステートレスコンテナです。成長をサポートするためにパーティショニングとシャーディングを使用します。 - パーソナライゼーション：ストリームプロセッサでのリアルタイム結合とキャッシュされたプロファイルストアにより、ユーザーごとのパーソナライゼーションが可能になります。事前計算されたセグメントは、オンザフライでのユーザーごとの評価を回避することで、大規模なファンアウト（フラッシュセール）を加速します。 トレードオフ（一貫性、可用性、コスト） - 一貫性対可用性：マーケティング通知では可用性と結果整合性を優先します（プロモーションがわずかに順序外で到着しても許容されます）。注文クリティカルなイベントについては、正しい順序と信頼性の高い配信を保証するために、より強力な順序付けと永続化（パーティショニングと同期永続化）を使用します。このハイブリッドアプローチは、ユーザーエクスペリエンスとシステムの回復力をバランスさせます。 - 少なくとも1回対正確に1回：パイプライン全体で正確に1回を達成するには、複雑さとコスト（トランザクションKafka、2フェーズコミット、またはエンドツーエンドの冪等性）が追加されます。システムをシンプルでスケーラブルに保ちながら、重複して表示される通知を回避するために、冪等ハンドラと重複排除キーを備えた少なくとも1回を選択します。 - マネージドサービス対セルフホスト：マネージドストリーミング（Kinesis/PubSub）とプッシュインフラストラクチャは、運用負荷を軽減し、可用性を向上させますが、コストが高くなります。市場投入までの速度とスケーラビリティにおける信頼性のために、マネージドサービスが推奨されます。コストが支配的になった場合は、強力な自動化を備えたセルフホストKafkaを検討してください。 運用上の考慮事項 - レート制限/スロットリング：過負荷とプロバイダーのレート制限拒否を回避するための、ユーザーごとおよびプロバイダーごとのクォータ。 - バックフィルと再生：耐久性のあるログを使用して、見逃した通知（例：障害後）を再生し、配信状態を再構築します。 - テスト：パーティションとプロバイダー障害のカオスエンジニアリング、ピーク時の99パーセンタイルレイテンシを検証するための負荷テスト。 - セキュリティとプライバシー：保存時のトークン暗号化、プッシュ認証情報のローテーション、オプトアウトの尊重、PII管理。 SLAと監視対象KPI - スループット（イベント/分）、ストリーム処理レイテンシ（p50/p90/p99）、エンドツーエンド配信レイテンシ（p50/p90/p99）、チャネルごとの配信成功率、リトライ率、キューラグ、コンシューマーグループラグ。 要約 この設計は、エンリッチメント/パーソナライゼーションのための耐久性のあるパーティション化されたイベントログとストリーム処理、ファンアウトのための永続化された配信パイプラインと自動スケーリングワーカー、そして高速配信のためのチャネル固有のコネクタ（APNs/FCM/WebSocket）を使用します。可用性と再生可能性を優先して少なくとも1回の配信を満たし、キャッシュとパーティショニングを使用して低レイテンシと高スループットを実現し、マネージドクラウドコンポーネントに依存して運用負荷を軽減しながら、将来の成長をサポートするために水平スケーリングを可能にします。

リアルタイムEコマース通知システムの設計 概要 提案するシステムは、イベント駆動型のマイクロサービスベースのアーキテクチャであり、複数のアップストリームサービスからイベントを取り込み、メッセージブローカーを通じて処理・ルーティングし、少なくとも1回の配信保証、99パーセンタイルで5秒未満のレイテンシ、ピークイベント時に毎分10万件の通知を維持する能力を備えて、モバイルおよびWebチャネル全体で5000万人のユーザーに通知を配信します。この設計はAWS上でのクラウドネイティブなデプロイを想定していますが、その原則はGCPまたはAzureの同等機能に直接適用できます。 高レベルアーキテクチャ アーキテクチャは、イベントプロデューサー、イベント取り込み、処理とルーティング、ユーザー設定とセグメンテーション、配信、オブザーバビリティの6つの論理レイヤーで構成されています。 1. イベントプロデューサー 複数のアップストリームサービスが、通知をトリガーするイベントを生成します。これには、注文サービス（注文済み、発送済み、配達中、配達完了イベントを発行）、価格サービス（監視対象アイテムの価格がしきい値を下回った場合に価格下落イベントを発行）、キャンペーンサービス（マーケティングチームによって作成されたフラッシュセール開始イベントを発行）が含まれます。各プロデューサーは、イベントタイプ、タイムスタンプ、ペイロード、冪等性キーを含む構造化されたイベントエンベロープを中央の取り込みレイヤーに発行します。プロデューサーは非同期のファイア・アンド・フォーゲット発行呼び出しを使用するため、それ自体のレイテンシには影響しません。 2. イベント取り込みレイヤー — Apache Kafka すべてのイベントはApache Kafka（AWSではAmazon MSK）に流れます。Kafkaが選択された理由はいくつかあります。第一に、設定可能なレプリケーション（レプリケーションファクター3、min.insync.replicas 2）を備えた耐久性のある追記専用ログを提供するため、確認された書き込みは単一のブローカーの損失に耐えることができ、信頼性要件に直接対応します。第二に、Kafkaのパーティション化されたトピックモデルは水平スケーリングを可能にします。注文イベントトピックをユーザーIDでパーティション化するため、特定のユーザーのすべてのイベントが順序通りに処理される一方で、全体的なトピックはピークスループットを吸収するために数十のパーティションに分散できます。毎分10万件の通知では、平均レートは約1,667イベント/秒であり、控えめなKafkaクラスターの容量内に十分に収まりますが、パーティショニングによりアーキテクチャの変更なしに10倍以上にスケールアップできます。第三に、Kafkaはプロデューサーとコンシューマーを分離するため、配信レイヤーの一時的な遅延が注文サービスにバックプレッシャーを与えません。 トピック設計：order-events、price-events、campaign-eventsの別々のトピック。これにより、異なるスケーリングおよびリトライポリシーを持つ独立したコンシューマーグループが可能になります。 検討されたトレードオフ：よりシンプルなマネージド代替としてAmazon SQSとSNSを評価しました。SQSは少なくとも1回の配信を保証し、運用負荷が軽いですが、Kafkaのパーティションごとの順序保証と、バグ後の再処理に役立つリプレイ機能が欠けています。Kafkaの追加の運用コストは、当社の規模での順序保証とリプレイのメリットによって正当化されます。 3. 処理とルーティングレイヤー — 通知サービス 水平スケーリングされたマイクロサービスである通知サービスは、Kafkaトピックから消費します。いくつかのタスクを実行します。第一に、ターゲットオーディエンスを解決します。注文イベントの場合、ターゲットは単一のユーザー（ペイロードから抽出）です。価格下落イベントの場合、そのアイテムを監視しているすべてのユーザーを見つけるために、Wishlist Serviceまたは事前に計算されたマテリアライズドビューにクエリを実行します。フラッシュセールイベントの場合、セグメンテーションサービスにクエリを実行してユーザーセグメントを解決します。第二に、ユーザーの表示名、製品画像URL、ローカライズされたメッセージテンプレートを、PostgreSQLストア上のRedisキャッシュによってバックアップされたテンプレートサービスから取得して、通知をエンリッチします。第三に、ユーザー設定を適用します。各ユーザーは、選択されたチャネル（プッシュ、メール、SMS、アプリ内）、サイレントアワー、カテゴリの興味を指定する設定ドキュメント（低レイテンシのキーバリューストアとしてDynamoDBに保存）を持っています。サービスはこれらの設定をフィルタリングして尊重し、パーソナライゼーション要件に直接対応します。第四に、配信タスクをファンアウトします。解決された各ユーザーチャネルペアについて、サービスはチャネルごとのKafkaトピック（push-delivery、email-delivery、sms-delivery、in-app-delivery）に配信メッセージを発行します。このファンアウトステップは重要です。1つの論理イベントを潜在的に数百万の個別の配信タスク（全ユーザーを対象としたフラッシュセールの場合）に変換し、Kafkaはこのバーストを吸収します。 スケーリング：通知サービスは、KafkaコンシューマーラグをキーとするHorizontal Pod Autoscalerを備えたKubernetesデプロイメント（Amazon EKS）として実行されます。フラッシュセール中にコンシューマーラグが急増し、数秒以内に追加のポッドが起動します。 冪等性：すべての配信メッセージには、元のイベントの冪等性キーとユーザーIDが組み合わされて含まれます。下流の配信ワーカーは、この複合キーを使用して重複排除を行うため、Kafkaは少なくとも1回のセマンティクスを提供しますが、ユーザーは重複通知を受け取りません。 4. ユーザー設定とセグメンテーション ユーザー設定はAmazon DynamoDBに保存され、ユーザーIDでパーティション化されます。DynamoDBは、シングルディジットミリ秒の読み取りレイテンシとシームレスな水平スケーリングのため選択されています。これは、すべての通知が設定ルックアップを必要とするため重要です。DAX（DynamoDB Accelerator）キャッシュがホットキーのために前面に配置されます。 セグメンテーション（カテゴリに関心のあるユーザーや地域にいるユーザーを対象とする）については、事前に計算されたセグメントメンバーシップリストを維持します。夜間のバッチジョブ（EMR上のApache Spark）とリアルタイムストリームプロセッサ（Kafka StreamsまたはFlink）が、これらのリストを別のDynamoDBテーブル（セグメントIDでキー付けされ、値は非常に大きなセグメントのためにS3に保存されたユーザーIDのリスト）で更新します。キャンペーンサービスがエレクトロニクスセグメントを対象とするフラッシュセールを作成すると、通知サービスはセグメントメンバーシップを読み取り、それを反復処理して、バッチで配信タスクを発行します。 トレードオフ：セグメントの事前計算は、ストレージと鮮度の低下（1時間前に設定を変更したユーザーがまだ古いセグメントに含まれている可能性がある）と引き換えにクエリ速度を向上させます。配信時のリアルタイムセグメント評価はより正確ですが、時間的制約の中で数百万のユーザーレコードをスキャンする必要があり、レイテンシ要件に違反します。ハイブリッドアプローチ（夜間バッチとリアルタイムストリーム更新）により、セグメントは数分以内に最新の状態に保たれます。 5. 配信レイヤー チャネルごとに個別のコンシューマーグループが処理します。 プッシュ通知（モバイル）：ワーカーはpush-deliveryトピックから消費し、Androidの場合はFirebase Cloud Messaging（FCM）、iOSの場合はApple Push Notification Service（APNs）を呼び出します。可能な限りFCMを両プラットフォームの統一ゲートウェイとして使用します。ワーカーは、スループットを最大化するために、FCMのHTTP v1 APIへのリクエストをバッチ処理します（バッチ呼び出しあたり最大500メッセージ）。配信失敗（無効なトークン、レート制限）は、指数関数的バックオフでリトライされます。永続的に失敗したトークン（登録されていないデバイス）は、User Device Registryからトークンを削除するための非同期イベントをトリガーします。 Webプッシュ：ワーカーはVAPID標準を使用してWebプッシュプロトコルメッセージを送信します。ユーザーのプッシュサブスクリプション（エンドポイントURLとキー）は、User Device Registry（DynamoDB）に保存されます。このチャネルは、チャネルサブタイプフィールドを持つ同じpush-deliveryトピックを再利用します。 アプリ内通知：現在オンラインのユーザーのために、永続的なWebSocket接続をAPI Gateway WebSocket API（AWS API Gateway WebSocketまたはEKS上のSocket.IOを使用した自己管理サービス）を通じて維持します。Connection Registry（Redis Cluster）は、ユーザーIDをWebSocket接続IDにマッピングします。アプリ内配信ワーカーは接続を検索し、ユーザーが接続している場合は通知をリアルタイムでプッシュします。接続されていない場合は、通知はIn-App Inbox（ユーザーIDでパーティション化され、タイムスタンプでソートされたDynamoDBテーブル）に書き込まれ、ユーザーが次にアプリを開いたときに配信されます。このデュアル書き込みにより、ユーザーがオフラインの場合でも通知が失われないことが保証されます。 メールとSMS：優先度の低いチャネル。ワーカーはemail-deliveryおよびsms-deliveryトピックから消費し、それぞれAmazon SESおよびAmazon SNS（SMS）を呼び出します。これらのチャネルはより高い許容レイテンシ（30秒から数分）を持つため、より保守的にスケーリングできます。 配信保証：少なくとも1回の配信はエンドツーエンドで保証されます。Kafkaコンシューマーは、下流の配信APIが受信を確認した後（またはメッセージがアプリ内インボックスに永続化された後）にのみオフセットをコミットします。ワーカーがコミット前にクラッシュした場合、メッセージは再配信されます。各ステージの冪等性キーにより、ユーザーに見える重複が抑制されます。 6. 通知ステータストラッキング 軽量なStatus Serviceは、各通知のライフサイクル（作成、送信、配信、既読）を記録します。FCM/APNsからの配信確認とクライアントアプリからの既読確認は、Kafkaトピックを通じて取り込まれ、分析のために時系列ストア（Amazon TimestreamまたはClickHouse）に、およびユーザーごとのステータス照会のためにDynamoDBに書き込まれます（これにより、アプリは未読/既読バッジを表示できます）。このデータはリトライロジックにもフィードされます。プッシュ通知が30秒以内に配信確認されない場合、システムはメールにフォールバックできます。 7. オブザーバビリティ PrometheusとGrafanaは、Kafkaコンシューマーラグ、配信レイテンシパーセンタイル、チャネルごとのエラー率、スループットを監視します。p99配信レイテンシが4秒を超えると（SLAの5秒前に1秒のバッファを与える）、アラートが発砲されます。分散トレーシング（OpenTelemetryとJaeger）は、イベントをプロデューサーから配信まで追跡し、迅速なデバッグを可能にします。構造化ログは、検索と監査のためにAmazon OpenSearchに送信されます。 要件への対応 高スループット：Kafkaのパーティション化されたトピックと水平スケーリングされたコンシューマーグループは、毎分10万件の通知を快適に処理します。大規模キャンペーンのファンアウトはKafkaのバッファリングによって吸収され、配信ワーカーはラグに基づいて自動スケーリングします。 低レイテンシ：単一ユーザー通知（例：注文発送済み）のクリティカルパスは次のとおりです。プロデューサーがKafkaに発行（50ms未満）、通知サービスが消費してエンリッチ（DynamoDBとRedisのルックアップを含む100ms未満）、配信ワーカーがFCM/APNsに送信（通常500ms未満）。合計で5秒未満です。大規模ファンアウトキャンペーンの場合、システムは多数の配信ワーカーに並列化されます。Kafkaのパーティショニングにより、単一のワーカーがボトルネックになることはありません。 信頼性：Kafkaのレプリケーション、コンシューマーオフセット管理、冪等配信により、少なくとも1回のセマンティクスが保証されます。設定可能なリトライ回数後に失敗したメッセージはデッドレターキュー（DLQ）トピックにキャプチャされ、運用チームに調査のためにアラートが送信されます。重要な注文通知は、優先度フィールドでフラッシュされ、専用の高優先度パーティションにルーティングされ、独自のコンシューマーグループを持つため、プロモーション通知の洪水によってスターベーションされることはありません。 スケーラビリティ：すべてのコンポーネントは水平にスケーリングします。Kafkaパーティションは増やすことができます。Kubernetesポッドは自動スケーリングします。DynamoDBはオンデマンドでスケーリングします。単一障害点や単一スレッドのボトルネックはありません。 パーソナライゼーション：DynamoDBのユーザー設定がチャネル選択とサイレントアワーを制御します。事前計算されたセグメントがターゲットキャンペーンを可能にします。テンプレートサービスは、ロケールごと、カテゴリごとのメッセージテンプレートをサポートし、エンリッチメント時にA/Bテストバリアントを選択できます。 主要なトレードオフと正当化 一貫性 vs 可用性：システムは可用性（CAP定理におけるA）を優先します。設定ストアが一時的に到達不能な場合、通知サービスはブロックするのではなく、キャッシュされた設定またはデフォルト設定を使用します。これは、ユーザーが最近オプトアウトしたチャネルで通知を時折受信する可能性があることを意味しますが、通知が失われたり遅延したりすることはありません。Eコマース通知システムにとって、可用性と低レイテンシは厳密な設定の一貫性よりも価値があります。 少なくとも1回 vs 厳密に1回：外部システム（FCM、APNs）全体での真の厳密に1回の配信は非現実的です。代わりに、少なくとも1回を保証し、アプリケーションレベルで重複を抑制するために冪等性キーを使用します。これはよりシンプルで、安価で、十分です。 マネージドサービス vs 自己ホスト：運用負荷を軽減するために、マネージドKafka（MSK）、マネージドKubernetes（EKS）、マネージドデータベース（DynamoDB）を使用します。トレードオフは、自己ホストと比較して単価が高いことですが、節約されたエンジニアリング時間とマネージドサービスの信頼性が、当社の規模ではこれを正当化します。 プッシュ vs プル（アプリ内）：WebSocket（プッシュ）は、オンラインユーザーにとって最も低いレイテンシを提供しますが、永続的な接続と接続レジストリの維持が必要です。ポーリングはよりシンプルですが、数秒のレイテンシを追加し、不要な負荷を生成します。ハイブリッドアプローチ（オンライン時はWebSocket、オフライン時はインボックス）は、レイテンシとリソース使用量のバランスを取ります。 コストに関する考慮事項：最大のコストドライバーは、Kafkaのスループット（MSKの価格設定）、設定ルックアップのためのDynamoDBの読み取り容量、およびFCM/APNs API呼び出し（FCMは無料ですが、大規模に呼び出すためのインフラストラクチャは無料ではありません）です。コストを管理するために、FCM呼び出しをバッチ処理し、DynamoDBのオンデマンド価格設定（スパイクワークロードに対して費用対効果が高い）を使用し、非クリティカルな配信ワーカー（メール、SMS）にスポットインスタンスを使用します。 結論 このアーキテクチャは、5000万ユーザーのEコマースプラットフォームに適した、堅牢でスケーラブル、低レイテンシの通知システムを提供します。Kafkaをセントラルニューラルシステムとして、DynamoDBを高速なユーザーデータアクセスに、そしてチャネル固有の配信ワーカーが独立して自動スケーリングするように活用することで、システムは運用管理可能で費用対効果の高い状態を維持しながら、すべての指定された要件を満たします。この設計は拡張可能です。新しい通知チャネル（例：WhatsApp）を追加するには、新しいKafkaトピックから消費する新しい配信ワーカーが必要なだけで、アップストリームのイベントプロデューサーやコア処理ロジックの変更は不要です。