Concevoir un service de notification en temps réel

Service de Notification en Temps Réel — Conception de Système de Haut Niveau ================================================================================ 0. ESTIMATION RAPIDE ================================================================================ - 10M DAU × 20 notifications/utilisateur/jour = 200M notifications/jour - 200M / 86 400 s ≈ 2 315 notifications/seconde (moyenne) - Charge de pointe (supposons 5× la moyenne) ≈ 11 575 notifications/seconde - Charge utile de chaque notification ~1 Ko → ~200 Go/jour d'ingestion de données brutes - Budget de latence : < 2 secondes de bout en bout (ingestion → livraison à l'appareil) ================================================================================ 1. ARCHITECTURE DE BASE ================================================================================ Le système suit une architecture microservices pilotée par les événements avec les composants clés suivants : ┌──────────────┐ │ Producteurs │ (Service de publication, Service de likes, Service de commentaires, Service de suivi, etc.) └──────┬───────┘ │ Événement de notification (gRPC / message asynchrone) ▼ ┌──────────────────┐ │ Passerelle API / │ Limitation de débit, authentification, routage │ Équilibreur de │ (par ex. AWS ALB / Envoy / Kong) │ charge │ └──────┬───────────┘ │ ▼ ┌──────────────────┐ │ Service de │ Service sans état (extensible horizontalement) │ Notification (SN)│ - Valide et déduplique les événements │ │ - Enrichit avec les préférences utilisateur │ │ - Diffuse vers les files d'attente par canal └──────┬───────────┘ │ Écrit l'enregistrement de notification dans la DB │ Publie dans la file de messages ▼ ┌──────────────────────────────────────────────────┐ │ File de messages / Broker │ │ (Apache Kafka — partitionné par hachage user_id)│ │ │ │ Sujets : push_notifications │ │ email_notifications │ │ in_app_notifications │ └──┬──────────────┬─────────────────┬──────────────┘ │ │ │ ▼ ▼ ▼ ┌────────┐ ┌──────────┐ ┌────────────────┐ │ Travailleur│ │ Travailleur│ │ Travailleur │ │ Push │ │ Email │ │ In-App │ │ Pool │ │ Pool │ │ Pool │ └───┬────┘ └────┬─────┘ └───────┬────────┘ │ │ │ ▼ ▼ ▼ ┌────────┐ ┌──────────┐ ┌────────────────┐ │ APNs / │ │ SES / │ │ Passerelle │ │ FCM │ │ SendGrid │ │ WebSocket │ └────────┘ └──────────┘ │ (connexions │ │ persistantes) │ └────────────────┘ Descriptions des composants : A) Passerelle API / Équilibreur de charge - Point d'entrée pour les services producteurs internes et les appels API externes (par ex. marquer comme lu). - Gère la limitation de débit, l'authentification et le routage des requêtes. - Distribue le trafic sur plusieurs instances du Service de Notification. B) Service de Notification (SN) - Microservice sans état déployé en plusieurs répliques derrière l'équilibreur de charge. - Reçoit les événements de notification, les valide, effectue la déduplication (vérification de la clé d'idempotence). - Recherche les préférences de notification de l'utilisateur dans un cache (Redis) ou une base de données. - Détermine sur quels canaux livrer (push, email, in-app) en fonction des préférences. - Persiste l'enregistrement de notification dans la base de données. - Publie des messages spécifiques au canal vers les sujets Kafka. C) File de messages (Apache Kafka) - Dissocie la création de la notification de sa livraison, absorbant les pics de trafic. - Partitionné par hachage user_id pour préserver l'ordre par utilisateur. - Offre la durabilité (facteur de réplication = 3) et la capacité de relecture. - Des sujets séparés par canal permettent une mise à l'échelle indépendante des consommateurs. D) Travailleurs de canal (Groupes de consommateurs) - Pool de travailleurs Push : Consomme du sujet push_notifications, regroupe les requêtes et envoie à APNs (iOS) et FCM (Android). Gère la gestion des jetons et la logique de nouvelle tentative. - Pool de travailleurs Email : Consomme du sujet email_notifications, rend les modèles et envoie via SES/SendGrid. Implémente un backoff exponentiel pour les échecs transitoires. - Pool de travailleurs In-App : Consomme du sujet in_app_notifications, envoie à la passerelle WebSocket pour une livraison en temps réel. Rebascule sur le polling si le WebSocket est déconnecté. E) Passerelle WebSocket - Maintient des connexions WebSocket persistantes avec les utilisateurs en ligne. - Extensible horizontalement ; utilise Redis Pub/Sub ou un bus de messages partagé afin que n'importe quel nœud de passerelle puisse livrer à n'importe quel utilisateur connecté. - Registre des connexions stocké dans Redis (mapping user_id → gateway_node). F) API de lecture des notifications - Chemin de lecture séparé pour récupérer l'historique des notifications, marquer comme lu, gérer les préférences. - Servi à partir de répliques de lecture / cache pour éviter d'impacter le chemin d'écriture. ================================================================================ 2. SCHÉMA DE BASE DE DONNÉES ================================================================================ Magasin de données principal : PostgreSQL (pour les préférences et métadonnées) + Cassandra (pour le stockage des notifications à grande échelle). --- PostgreSQL (Préférences et métadonnées utilisateur) --- TABLE : users user_id UUID PRIMARY KEY email VARCHAR(255) phone VARCHAR(50) created_at TIMESTAMP updated_at TIMESTAMP TABLE : notification_preferences user_id UUID PRIMARY KEY REFERENCES users(user_id) push_enabled BOOLEAN DEFAULT TRUE email_enabled BOOLEAN DEFAULT TRUE in_app_enabled BOOLEAN DEFAULT TRUE quiet_hours_start TIME NULLABLE quiet_hours_end TIME NULLABLE email_digest_freq ENUM('instant', 'hourly', 'daily') DEFAULT 'instant' -- Surcharges par catégorie likes_push BOOLEAN DEFAULT TRUE likes_email BOOLEAN DEFAULT FALSE comments_push BOOLEAN DEFAULT TRUE comments_email BOOLEAN DEFAULT TRUE follows_push BOOLEAN DEFAULT TRUE follows_email BOOLEAN DEFAULT FALSE mentions_push BOOLEAN DEFAULT TRUE mentions_email BOOLEAN DEFAULT TRUE updated_at TIMESTAMP TABLE : device_tokens token_id UUID PRIMARY KEY user_id UUID REFERENCES users(user_id) platform ENUM('ios', 'android', 'web') device_token VARCHAR(512) is_active BOOLEAN DEFAULT TRUE created_at TIMESTAMP updated_at TIMESTAMP INDEX idx_device_user (user_id) --- Cassandra (Stockage des notifications — optimisé pour les lectures de séries chronologiques) --- TABLE : notifications user_id UUID -- Clé de partition created_at TIMEUUID -- Clé de clustering (DESC) notification_id UUID type TEXT -- 'like', 'comment', 'follow', 'mention', 'system' actor_id UUID target_entity_type TEXT -- 'post', 'comment', 'profile' target_entity_id UUID message TEXT is_read BOOLEAN channels_delivered SET<TEXT> -- {'push', 'email', 'in_app'} metadata TEXT -- Blob JSON pour l'extensibilité PRIMARY KEY ((user_id), created_at) WITH CLUSTERING ORDER BY (created_at DESC) AND default_time_to_live = 7776000 -- TTL de 90 jours TABLE : notification_counts (table matérialisée/compteur) user_id UUID PRIMARY KEY unread_count COUNTER --- Redis (Couche de mise en cache) --- - Cache des préférences utilisateur : Clé = pref:{user_id}, TTL = 10 min - Cache du nombre de non lus : Clé = unread:{user_id}, TTL = 5 min - Ensemble de déduplication : Clé = dedup:{idempotency_key}, TTL = 24 heures - Registre des connexions WebSocket : Clé = ws:{user_id} → id_nœud_passerelle ================================================================================ 3. STRATÉGIE DE MISE À L'ÉCHELLE ================================================================================ A) Mise à l'échelle horizontale des services sans état - Le Service de Notification, tous les Pools de Travailleurs et la Passerelle WebSocket sont sans état et extensibles horizontalement. - Groupes d'auto-mise à l'échelle (HPA Kubernetes) basés sur les métriques CPU, mémoire et retard de file d'attente. - Objectif : chaque instance SN gère ~500 req/s ; besoin de ~25 instances au pic. B) Partitionnement Kafka - Commencer avec 64 partitions par sujet (permet jusqu'à 64 consommateurs par groupe). - Partitionner par hachage user_id pour garantir l'ordre par utilisateur. - Augmenter le nombre de partitions à mesure que le débit augmente (repartitionner avec soin). - Des groupes de consommateurs séparés par canal permettent une mise à l'échelle indépendante. C) Mise à l'échelle de la base de données - Cassandra : Extensible horizontalement naturellement. Commencer avec un cluster de 6 nœuds (RF=3). Ajouter des nœuds à mesure que le volume de données augmente. Clé de partition = user_id distribue la charge uniformément. - PostgreSQL : Mise à l'échelle verticale initialement pour les préférences (ensemble de données relativement petit : 10M lignes). Ajouter des répliques de lecture pour les recherches de préférences à forte demande de lecture. Envisager le sharding par user_id si nécessaire. - Cluster Redis : 3 nœuds ou plus avec sharding automatique pour le cache et le registre des connexions. D) Mise à l'échelle de la passerelle WebSocket - Chaque nœud de passerelle gère ~100K connexions simultanées. - 10M DAU avec ~30% de simultanés en ligne = 3M connexions → ~30 nœuds de passerelle. - Redis Pub/Sub ou un bus de messages léger (par ex. NATS) pour le routage des messages inter-nœuds. - Hachage cohérent pour l'affectation utilisateur-nœud avec rééquilibrage gracieux. E) Limitation de débit et contre-pression - Limiter le débit des producteurs de notifications pour éviter les abus (par ex. max 1000 événements/sec par producteur). - Surveillance du retard des consommateurs Kafka avec alertes ; mise à l'échelle automatique des consommateurs lorsque le retard dépasse le seuil. - Disjoncteurs sur les services externes (APNs, FCM, SES) pour éviter les défaillances en cascade. F) Chemin de croissance future - Passer à un déploiement multi-régions avec Kafka MirrorMaker 2 pour la réplication inter-régions. - Introduire une couche d'agrégation/regroupement de notifications (par ex. « X et 5 autres personnes ont aimé votre publication »). - Ajouter une file d'attente prioritaire pour les notifications sensibles au temps (par ex. messages directs vs notifications de likes). ================================================================================ 4. FIABILITÉ ET TOLÉRANCE AUX PANNES ================================================================================ A) Durabilité des données - Kafka : Facteur de réplication = 3, min.insync.replicas = 2, acks = all. Garantit aucune perte de données même si un broker tombe en panne. - Cassandra : Facteur de réplication = 3, cohérence d'écriture = QUORUM (2 sur 3). Tolère la défaillance d'un seul nœud sans perte de données. - PostgreSQL : Réplication synchrone vers au moins une réplique de secours. B) Livraison au moins une fois - Les consommateurs Kafka ne valident les offsets qu'après un traitement réussi. - Les travailleurs implémentent une livraison idempotente en utilisant notification_id comme clé de déduplication. - Si une livraison push/email échoue, le message reste dans Kafka pour être retenté. - File de messages morts (DLQ) pour les messages qui échouent après N tentatives (par ex. 5 tentatives avec backoff exponentiel). C) Haute disponibilité (objectif 99,9 % = max 8,76 heures d'indisponibilité/an) - Tous les services déployés sur 3 zones de disponibilité (AZ). - Kubernetes avec des règles d'anti-affinité de pods garantit que les répliques sont réparties sur les AZ. - Les clusters de bases de données s'étendent sur plusieurs AZ avec basculement automatique. - Vérifications de santé de l'équilibreur de charge avec suppression automatique des instances non saines. - Déploiements blue-green ou canary pour minimiser les temps d'arrêt liés au déploiement. D) Dégradation gracieuse - Si le service de notification push (APNs/FCM) est en panne, les notifications sont mises en file d'attente dans Kafka et retentées. - Si la passerelle WebSocket est surchargée, les clients reviennent au polling de l'API de lecture des notifications. - Si Cassandra est temporairement indisponible, les notifications sont mises en mémoire tampon dans Kafka (qui a une rétention de plusieurs jours). - Modèle de disjoncteur sur toutes les dépendances externes avec comportement de repli. E) Surveillance et alertes - Suivi de la latence de bout en bout : horodatage à la création → horodatage à la livraison (P50, P95, P99). - Surveillance du retard des consommateurs Kafka par sujet et groupe de consommateurs. - Tableaux de bord du taux d'erreur par canal (taux d'échec push, taux de rebond email). - Alertes sur : latence > 2s à P95, retard du consommateur > 10K messages, taux d'erreur > 1 %, disponibilité < 99,9 %. F) Reprise après sinistre - Données des sujets Kafka conservées pendant 7 jours, permettant la relecture à partir de n'importe quel point. - Instantanés Cassandra pris quotidiennement, stockés dans S3 avec réplication inter-régions. - Archivage des journaux WAL PostgreSQL vers S3 pour une récupération à un point dans le temps. - Livre d'exécution pour la récupération complète du cluster avec un RTO cible < 1 heure, RPO < 5 minutes. ================================================================================ 5. ARBITRAGES CLÉS ================================================================================ Arbitrage 1 : Disponibilité vs Cohérence Stricte (AP plutôt que CP) Décision : Nous avons choisi la cohérence éventuelle pour la livraison des notifications et le statut de lecture. - Cassandra avec des écritures QUORUM offre une cohérence suffisamment forte pour les notifications tout en privilégiant la disponibilité et la tolérance aux partitions. - Un utilisateur peut brièvement voir un nombre de non lus obsolète (mis en cache dans Redis avec un TTL de 5 minutes), mais cela est acceptable pour un système de notification où une précision parfaite en temps réel des comptes n'est pas critique. - L'alternative — utiliser une base de données à cohérence forte comme PostgreSQL pour tout le stockage des notifications — créerait un goulot d'étranglement de mise à l'échelle à 200 millions d'écritures/jour et risquerait la disponibilité lors de partitions réseau. - Impact : Les utilisateurs peuvent occasionnellement voir un nombre de notifications erroné de 1 à 2 pendant quelques secondes. C'est un problème d'UX mineur par rapport au risque que l'ensemble du système de notification devienne indisponible. Arbitrage 2 : Modèle Push (WebSockets) vs Modèle Pull (Polling) pour les notifications In-App Décision : Nous avons choisi un modèle push d'abord utilisant WebSockets avec le polling comme solution de repli. - Le push via WebSockets livre les notifications en temps réel (moins d'une seconde), respectant notre exigence de latence < 2s. - Cependant, le maintien de millions de connexions persistantes est gourmand en ressources (~30 nœuds de passerelle pour 3 millions de connexions simultanées) et ajoute une complexité opérationnelle (gestion des connexions, battements de cœur, logique de reconnexion). - L'alternative — le polling pur — serait plus simple à exploiter mais augmenterait soit la latence (si l'intervalle de polling est long), soit la charge du serveur de manière spectaculaire (si l'intervalle de polling est court). Avec 3 millions d'utilisateurs simultanés qui interrogent toutes les 2 secondes = 1,5 million de req/s juste pour le polling, ce qui est beaucoup plus coûteux que de maintenir des connexions WebSocket. - Compromis : Nous utilisons des WebSockets pour les utilisateurs en ligne et revenons au polling (avec des intervalles plus longs) lorsque les connexions WebSocket ne peuvent pas être établies (par ex. pare-feux restrictifs). Les notifications push via APNs/FCM gèrent le cas où l'utilisateur est hors ligne. Arbitrage 3 : Magasin de notifications unique (Cassandra) vs Persistance Polyglotte Décision : Nous utilisons Cassandra pour le stockage des notifications et PostgreSQL pour les préférences/métadonnées utilisateur plutôt qu'une seule base de données pour tout. - Cassandra excelle dans les écritures de séries chronologiques à haut débit (200M/jour) et les lectures basées sur la clé de partition (récupérer les notifications pour un utilisateur), ce qui est le modèle d'accès dominant. - PostgreSQL est mieux adapté à la nature relationnelle des préférences utilisateur (jointures avec la table utilisateur, mises à jour transactionnelles des préférences). - Le compromis est une complexité opérationnelle accrue (deux systèmes de bases de données à maintenir, surveiller et sauvegarder) et la nécessité de maintenir la cohérence des données entre les systèmes (par ex. si un utilisateur est supprimé, les notifications doivent être nettoyées dans Cassandra). - Nous atténuons cela avec un processus de nettoyage piloté par les événements : les événements de suppression d'utilisateur déclenchent des tâches de nettoyage asynchrones dans Cassandra. Arbitrage 4 : Au moins une fois vs Livraison exactement une fois Décision : Nous avons choisi des sémantiques de livraison au moins une fois avec déduplication au niveau de l'application. - La livraison exactement une fois dans les systèmes distribués est extrêmement coûteuse et complexe (nécessite des transactions distribuées ou les sémantiques exactement une fois de Kafka avec une surcharge de performance significative). - Au moins une fois est plus simple et plus performant. Les notifications dupliquées sont gérées au niveau de l'application à l'aide de clés d'idempotence (notification_id vérifié avant la livraison). - Le risque est que dans de rares scénarios de défaillance, un utilisateur puisse recevoir une notification push dupliquée. C'est une nuisance mineure par rapport à l'alternative de notifications perdues (au plus une fois) ou à la complexité/coût de performance de exactement une fois. ================================================================================ RÉSUMÉ ================================================================================ Cette conception gère 200 millions de notifications/jour sur trois canaux avec une latence de livraison inférieure à 2 secondes. L'architecture pilotée par les événements avec Kafka comme système nerveux central assure la durabilité, le découplage et la gestion naturelle de la contre-pression. Cassandra fournit un stockage de notifications extensible horizontalement, tandis que la passerelle WebSocket permet une livraison in-app en temps réel. Le système est conçu pour une disponibilité de 99,9 % grâce au déploiement multi-AZ, à la réplication à chaque niveau et aux modèles de dégradation gracieuse. Les arbitrages clés privilégient la disponibilité, l'évolutivité et la simplicité opérationnelle par rapport à la cohérence stricte et aux sémantiques de livraison exactement une fois, ce qui sont des choix appropriés pour un système de notification où une légère obsolescence occasionnelle ou de rares doublons sont acceptables.

Conception de haut niveau 1. Architecture de base Une bonne conception est pilotée par les événements, consciente des canaux et privilégie la durabilité. Flux principal - Les services de produits tels que les J'aime, les Commentaires, les Abonnements, les Mentions, les Messages publient des événements dignes de notification. - L'API Gateway ou l'API interne d'ingestion d'événements reçoit des requêtes directes si nécessaire, mais la plupart du trafic devrait provenir des flux d'événements internes. - Le Notification Orchestrator valide l'événement, le déduplique, étend les destinataires, vérifie les préférences de l'utilisateur, crée un enregistrement de notification durable et émet des tâches de diffusion par canal. - La File de messages / le Bus d'événements met en mémoire tampon le travail pour les agents de canal en aval. - Les agents de canal gèrent la diffusion push, par e-mail et dans l'application indépendamment. - Le service d'état de livraison met à jour l'état de la notification et retente si nécessaire. - Les API de lecture servent la boîte de réception des notifications et les comptes non lus aux clients. - La passerelle WebSocket / SSE peut pousser les mises à jour dans l'application en temps réel aux utilisateurs en ligne. Composants clés - API Gateway - Authentification, limitation de débit, routage, observabilité. - Utilisé pour les API de lecture client et les API d'administration. - Bus d'événements / Flux d'ingestion - Journal durable de type Kafka / Pulsar. - Producteurs : graphe social, contenu, messagerie, modération, etc. - Sujet partitionné par user_id du destinataire pour préserver l'ordre par utilisateur lorsque cela est utile. - Notification Orchestrator - Service sans état consommant des événements. - Responsabilités : - validation du schéma - vérification de l'idempotence à l'aide de l'event_id ou de la clé de déduplication - décision de diffusion - recherche des préférences - sélection du modèle - classification de la priorité - persistance de l'enregistrement de notification canonique - mise en file d'attente des tâches de livraison par canal - Écrit d'abord, puis planifie la livraison, de sorte que les données ne soient pas perdues. - Service de préférences - Renvoie les paramètres de canal au niveau de l'utilisateur, les heures de tranquillité, les jetons d'appareil, la locale, l'état de vérification de l'e-mail. - Soutenu par un magasin de préférences utilisateur fortement cohérent plus un cache. - Magasin de notifications - Magasin durable canonique pour les métadonnées de notification et les enregistrements de la boîte de réception utilisateur. - Optimisé pour les écritures et les lectures récentes. - File de diffusion - Files d'attente/sujets séparés par canal : push, e-mail, dans l'application. - Permet des politiques de nouvelle tentative et de débit différentes. - Agent Push - S'intègre avec APNS/FCM. - Gère l'invalidation des jetons, les charges utiles spécifiques à la plateforme, la rétrogradation exponentielle. - Agent E-mail - S'intègre avec le fournisseur d'e-mails. - Priorité plus faible que le push/dans l'application pour la plupart des événements sociaux. - Suivi des rebonds, des plaintes, de la liste de suppression. - Agent de diffusion dans l'application - Écrit dans le magasin de la boîte de réception et, si l'utilisateur est en ligne, pousse via WebSocket/SSE. - Si hors ligne, la notification reste disponible via la récupération de l'API de la boîte de réception. - Passerelle temps réel - Maintient des connexions client persistantes pour les utilisateurs actifs. - S'abonne aux événements de diffusion dans l'application et envoie en moins de 2 secondes. - API de lecture / Service de boîte de réception - Liste les notifications, marque comme lues, compte non lus, pagination. - Lit à partir du magasin de la boîte de réception des notifications et du cache. - Processeur de nouvelle tentative / Lettre morte - Retente les échecs transitoires. - DLQ pour les messages empoisonnés ou les échecs permanents. - Prend en charge la relecture. - Pile d'observabilité - Métriques : latence de mise en file d'attente à diffusion, taux de succès par canal, nombre de nouvelles tentatives, décalage de la file d'attente. - Journaux et traçage distribué. - Alertes sur les violations de SLA. Séquence d'interaction - Un service de commentaires émet l'événement CommentCreated. - Le bus d'événements stocke l'événement de manière durable. - Le Notification Orchestrator consomme l'événement, détermine l'utilisateur destinataire, vérifie les préférences, crée une ligne de notification et émet des tâches vers : - la file d'attente dans l'application - la file d'attente push si activée et suffisamment urgente - la file d'attente e-mail si configurée - L'agent dans l'application stocke l'élément de la boîte de réception et pousse via WebSocket si l'utilisateur est en ligne. - L'agent push envoie à FCM/APNS. - Les accusés de réception/mises à jour de statut de livraison sont renvoyés. - L'utilisateur peut récupérer la boîte de réception complète via l'API de lecture. Estimation du débit - 10M DAU × 20 notifications/jour = 200M notifications/jour. - Débit moyen = environ 2 315 notifications/sec. - Les systèmes réels ont des pics, donc concevez pour au moins 10x de marge de pointe : 20k à 30k créations de notifications/sec, avec une diffusion par canal rendant la livraison en aval plus élevée. - Cette échelle est très gérable avec des files d'attente partitionnées et des agents sans état mis à l'échelle horizontalement. 2. Schéma de base de données Utiliser un modèle divisé : - magasin durable transactionnel pour les enregistrements de notification canoniques et les préférences - cache pour les lectures fréquentes - magasin de recherche/index optionnel pour les requêtes avancées de boîte de réception Schéma de base users_notification_preferences - user_id PK - push_enabled booléen - email_enabled booléen - in_app_enabled booléen - quiet_hours_start - quiet_hours_end - timezone - locale - email_address - email_verified booléen - push_tokens json / table séparée - notification_type_settings json ou table enfant normalisée - updated_at user_device_tokens - token_id PK - user_id - platform - device_token - app_version - last_seen_at - is_active - unique(device_token) - index(user_id) notifications - notification_id PK - recipient_user_id - actor_user_id nullable - type - object_type - object_id - dedupe_key - title - body - payload json - priority - created_at - expire_at nullable - aggregation_key nullable - source_event_id unique - index : - (recipient_user_id, created_at desc) - (recipient_user_id, notification_id) - unique(source_event_id) ou unique(dedupe_key) notification_deliveries - delivery_id PK - notification_id - channel enum(push, email, in_app) - status enum(pending, sent, delivered, failed, suppressed) - provider_message_id nullable - attempt_count - last_attempt_at - next_retry_at nullable - failure_reason nullable - delivered_at nullable - index : - (notification_id) - (channel, status, next_retry_at) notification_reads - notification_id - user_id - read_at - primary key(notification_id, user_id) - index(user_id, read_at) Optimisation optionnelle : table user_inbox - user_id - notification_id - created_at - read_state - primary key(user_id, created_at, notification_id) Ceci peut être la table principale dans un magasin à colonnes larges pour la récupération de la boîte de réception. Choix de stockage - Préférences : base de données relationnelle ou magasin clé-valeur fortement cohérent. - Notifications/boîte de réception : Cassandra/DynamoDB/Bigtable-style KV à colonnes larges est attrayant car le modèle d'accès est principalement par user_id et lectures récentes ordonnées dans le temps, avec un volume d'écriture très élevé. - Audit/état de livraison : magasin relationnel ou KV en fonction des besoins de reporting. - Cache : Redis pour les comptes non lus et les dernières pages de la boîte de réception. 3. Stratégie de mise à l'échelle Mise à l'échelle horizontale - Tous les services sans état sont mis à l'échelle horizontale automatiquement : orchestrateur, agents de canal, API de lecture, passerelles WebSocket. - Partitionner les sujets d'événements par recipient_user_id pour répartir uniformément la charge et préserver l'ordre par utilisateur. - Séparer les files d'attente par canal et par priorité afin que le retard des e-mails n'affecte pas la latence du push. Mise à l'échelle des données - Fragmenter les données de notification par user_id. - Utiliser le partitionnement temporel si nécessaire pour les utilisateurs très importants, par exemple clé de partition (user_id, mois). - TTL pour les notifications plus anciennes de faible valeur après la politique de rétention si le métier le permet, tout en archivage vers un stockage objet peu coûteux. - Mettre en cache les comptes non lus et les N dernières notifications. Façonnage du trafic - Couloirs de priorité : - élevé : mentions directes, messages, alertes de sécurité - moyen : commentaires, j'aime - bas : activité digestible ou articles promotionnels - Pendant les pics, protéger d'abord les notifications de haute priorité. - Regrouper la génération d'e-mails de faible priorité. Stratégie de diffusion - Préférer la diffusion à l'écriture pour la boîte de réception par utilisateur et les canaux en temps réel car la cible de latence est inférieure à 2 secondes. - Pour les événements de diffusion extrêmement importants, comme les publications de célébrités à des millions de personnes, utiliser une gestion hybride : - créer un événement grossier une fois - diffuser de manière asynchrone par lots - potentiellement dégrader les canaux non critiques en digest ou en livraison différée Ceci évite les estampilles. Mise à l'échelle géographique - Actif-actif multi-régions pour les API d'ingestion et de diffusion. - Maintenir l'affinité utilisateur avec la région d'origine lorsque possible pour réduire les écritures inter-régions. - Répliquer les métadonnées critiques globalement. - Les fournisseurs de canaux sont appelés depuis la région la plus proche. Planification de la capacité - 200M/jour de notifications canoniques. - Si chacune crée en moyenne 2 à 3 tentatives par canal, les enregistrements de livraison en aval peuvent être de 400M à 600M/jour. - Utiliser des partitions de file d'attente dimensionnées pour le débit de pointe, par exemple des dizaines à des centaines de partitions selon le courtier. - Passerelle WebSocket dimensionnée par utilisateurs en ligne concurrents, pas par DAU. 4. Fiabilité et tolérance aux pannes Cible de disponibilité : 99,9 % - Déploiement multi-AZ pour chaque niveau. - Aucun point de défaillance unique. - Équilibreurs de charge entre les instances. - Courtier et base de données gérés avec réplication. Aucune perte de données de notification - Persister la notification canonique avant les tentatives de livraison. - Utiliser un journal/file d'attente durable avec un facteur de réplication >= 3. - Consommateurs idempotents et nouvelles tentatives du producteur. - Modèle Outbox pour les services producteurs en amont s'ils émettent des événements de notification à partir d'opérations transactionnelles. - Exemple : une écriture de commentaire et un événement de notification sont liés à l'aide d'une transaction de base de données + outbox pour éviter les événements perdus. - Capacité de relecture à partir du journal d'événements et de la DLQ. Gestion des pannes - Livraison au moins une fois en interne, avec déduplication au niveau de l'orchestrateur et des canaux. - Nouvelles tentatives avec rétrogradation exponentielle pour les échecs transitoires du fournisseur. - DLQ pour les tâches malformées ou échouant de manière répétée. - Disjoncteurs autour des fournisseurs APNS/FCM/e-mail. - Comportement de repli : - si le fournisseur push est dégradé, stocker quand même la notification dans l'application - si le fournisseur d'e-mails est en panne, garder en file d'attente et réessayer plus tard Cohérence et intégrité des données - source_event_id unique ou clé de déduplication empêche la création de notifications en double. - La machine d'état de livraison évite les transitions invalides. - Cohérence forte pour les mises à jour des préférences si un effet immédiat est requis, sinon une cohérence limitée via l'invalidation du cache. Reprise après sinistre - Métadonnées et sauvegardes répliquées inter-régions. - Instantanés périodiques plus rétention WAL/binlog ou flux. - RPO défini proche de zéro en utilisant un journal durable répliqué. - RTO minimisé avec l'infrastructure en tant que code et la conception en veille active/active. Fiabilité opérationnelle - SLO pour la latence de mise en file d'attente à persistance et de persistance à diffusion. - Alarmes de décalage de file d'attente. - Sondes synthétiques pour les chemins push/e-mail/dans l'application. - Contrôles de contre-pression lorsque les fournisseurs en aval limitent. - Limites de débit par locataire/type d'événement pour contenir les abus. 5. Compromis clés Compromis 1 : Livraison au moins une fois vs livraison exactement une fois - Choisi : au moins une fois avec idempotence. - Pourquoi : exactement une fois entre les courtiers, les bases de données et les fournisseurs externes comme APNS/FCM/e-mail est coûteux et souvent impraticable. - Impact : des tentatives en double occasionnelles sont possibles, mais les clés de déduplication et les écritures idempotentes rendent les doublons visibles par l'utilisateur rares. - Avantage : beaucoup plus simple et plus fiable en cas de panne. Compromis 2 : Magasin à colonnes larges/KV vs base de données relationnelle pour la boîte de réception des notifications - Choisi : magasin à colonnes larges ou de style Dynamo pour la boîte de réception, relationnel pour les préférences et certains métadonnées. - Pourquoi : la charge de travail des notifications est à forte écriture, à forte appending et lit principalement par utilisateur et par récence. - Impact : capacité de requête ad hoc plus faible et modélisation des données plus soignée. - Avantage : échelle horizontale bien meilleure et performances prévisibles. Compromis 3 : Diffusion à l'écriture vs diffusion à la lecture - Choisi : principalement diffusion à l'écriture. - Pourquoi : exigence de latence inférieure à 2 secondes et besoin d'immédiateté pour le push/dans l'application. - Impact : plus d'amplification d'écriture, en particulier pour les événements à forte diffusion. - Atténuation : approche hybride pour les méga-diffusions. Compromis 4 : Diffusion push en temps réel vs boîte de réception par simple interrogation - Choisi : hybride. - Pourquoi : le push/WebSocket offre une faible latence pour les utilisateurs actifs, l'API d'interrogation offre une résilience pour les utilisateurs hors ligne. - Impact : complexité accrue du système car l'état de la connexion et la persistance de la boîte de réception sont requis. - Avantage : meilleure expérience utilisateur et fiabilité. Résumé de l'architecture finale suggérée - Ingestion des événements via un bus d'événements durable. - Utilisation d'un Notification Orchestrator sans état pour dédupliquer, vérifier les préférences, persister les enregistrements de notification et publier les tâches spécifiques au canal. - Stockage des données de la boîte de réception dans un magasin partitionné par utilisateur et évolutif horizontalement, avec un magasin KV relationnel ou fortement cohérent pour les préférences. - Diffusion via des agents push, e-mail et dans l'application dédiés. - Utilisation de WebSocket/SSE pour les mises à jour dans l'application en temps réel et des API de lecture normales pour la récupération de la boîte de réception. - Assurer la fiabilité grâce au déploiement multi-AZ, aux files d'attente répliquées, aux écritures privilégiant la durabilité, à l'idempotence, aux nouvelles tentatives, aux DLQ, à la relecture et à la reprise après sinistre inter-régions. Cette conception prend en charge confortablement 10 millions d'utilisateurs actifs par jour et 200 millions de notifications par jour, tout en respectant une livraison en moins de 2 secondes pour la plupart des notifications en temps réel et en maintenant une disponibilité de 99,9 % sans perte de données.