Conception du système : Service de notifications en temps réel

SERVICE DE NOTIFICATION EN TEMPS RÉEL — PLAN DE CONCEPTION DU SYSTÈME

1. RÉCAPITULATIF DES EXIGENCES ET ESTIMATION DE LA CAPACITÉ

Mathématiques du trafic :

• 100M d'utilisateurs actifs quotidiens x 10 événements/jour = 1 milliard d'événements déclenchant des notifications par jour.
• Moyenne = 1 milliard / 86 400 ≈ 11 600 événements/sec. Pic à 5x ≈ 58 000 événements/sec.
• Multiplicateur de diffusion (fan-out) : la plupart des événements (like, commentaire, suivi, DM) ciblent exactement un destinataire, donc le fan-out est d'environ 1:1. Cependant, les événements provenant de comptes à forte audience (une célébrité publie) peuvent se diffuser à des millions de destinataires ; traitez-les comme un chemin distinct de « diffusion en bloc ». Supposons une livraison de pointe effective de 80 000 à 100 000 notifications/sec, y compris les campagnes de masse.
• Stockage : historique des 100 dernières notifications par utilisateur. Supposons environ 400 octets par ligne -> 100 x 400 octets = 40 Ko/utilisateur -> 100 millions d'utilisateurs ≈ 4 To d'historique « chaud », plus un facteur de réplication de 3 ≈ 12 To. Facilement partageable.
• Connexions : supposons que 20 à 25 % des utilisateurs actifs quotidiens soient connectés simultanément au pic ≈ 20 à 25 millions de connexions WebSocket actives. Avec environ 100 000 connexions par nœud passerelle (Linux optimisé, epoll), cela représente 200 à 250 nœuds plus une marge.

Cibles non fonctionnelles :

• Latence p99 de bout en bout inférieure à 2 secondes pour les utilisateurs en ligne (mesurée de l'ingestion de l'événement à l'accusé de réception du client).
• Disponibilité de 99,9 % = environ 43 minutes d'indisponibilité par mois.
• Livraison au moins une fois avec déduplication côté client/serveur idempotente.

2. ARCHITECTURE DE HAUT NIVEAU

La conception est un pipeline piloté par les événements avec une séparation claire entre le chemin d'ingestion (rapide, durable, optimisé pour l'écriture) et le chemin de livraison (spécifique au canal, avec tentatives).

Flux :
Services producteurs (Service de publication, Service de graphe social, Service de commentaires, Service de messagerie)
-> API de notification / Passerelle (gRPC + REST, authentification, limitation de débit, validation de schéma, clé d'idempotence)
-> Sujet Kafka notification.events (partitionné par recipient_user_id si connu, sinon par actor_id)
-> Service de diffusion (résout les destinataires, développe les événements de célébrités, applique les règles d'agrégation)
-> Sujet Kafka notification.deliveries (un message par destinataire)
-> Service de préférences et de politique (recherche en ligne via cache : opt-ins de canal, heures de silence, mise en sourdine/blocage, résumé vs instantané)
-> Routeur / Répartiteur écrit dans des sujets par canal :
deliver.websocket, deliver.mobile_push, deliver.web_push, deliver.email
-> Travailleurs de canal :
Répartiteur WebSocket -> Recherche dans le registre de connexion -> Nœud de passerelle en temps réel -> client
Travailleur Push Mobile -> APNs (iOS) / FCM (Android)
Travailleur Push Web -> Protocole VAPID/Web Push via les services de push des navigateurs
Travailleur Email -> SES / SendGrid, avec rendu de modèles et regroupement de résumés
-> En parallèle, un consommateur d'écriture d'historique persiste chaque livraison dans le magasin d'historique des notifications et incrémente les compteurs de non lus.

Transversal : Service de modèles, Registre d'appareils, Registre de connexion, Magasin de déduplication, Files d'attente de lettres mortes, Pile d'observabilité, et un plan d'administration/analyse consommant les mêmes flux Kafka.

3. COMPOSANTS CLÉS ET RESPONSABILITÉS

Passerelle API de notification

• Point d'entrée unique pour les producteurs internes (gRPC, schémas protobuf dans un registre) et pour les API de lecture client (REST/GraphQL pour l'historique, marquer comme lu, préférences).
• Responsabilités : authentification (service à service mTLS, JWT pour les clients), limitation de débit/quotas par locataire et par producteur, validation des requêtes, acceptation de la clé d'idempotence, et ajout immédiat et durable à Kafka. Elle renvoie rapidement 202 Accepted ; elle n'effectue aucun travail de livraison en ligne.

Ingestion d'événements / Kafka

• Journal durable et rejouable. notification.events avec environ 256 partitions, facteur de réplication 3, min.insync.replicas=2, acks=all, rétention 7 jours pour la relecture et la récupération d'incidents.
• Fournit une contre-pression et un tampon naturels pour le pic 5x, découplant les producteurs des fournisseurs tiers lents.

Service de diffusion (Fan-out Service)

• Résout un événement en une liste de destinataires. Pour les événements 1:1, c'est un passage direct. Pour les événements 1:N (nouveau post aux abonnés, activité de fil de discussion de groupe), il interroge le service de graphe social et émet des messages de destinataires par lots.
• Stratégie de diffusion hybride : basée sur le push (écriture par destinataire) pour les comptes normaux ; basée sur le pull/paresseuse pour les comptes au-dessus d'un seuil d'abonnés (par exemple, 1 million et plus), où un seul « marqueur de flux » est écrit et les destinataires sont matérialisés à la lecture. Cela évite qu'un événement de célébrité ne crée une tempête d'écriture de 50 millions de messages sur le chemin critique.
• Limite le débit des expansions en bloc sur un sujet Kafka distinct de faible priorité afin qu'elles ne privent jamais les notifications interactives.
• Applique l'agrégation/coalescence : « Alice et 24 autres personnes ont aimé votre publication » au lieu de 25 lignes, en utilisant une fenêtre glissante courte (par exemple, 30 à 60 secondes) indexée par (destinataire, post_id, type) dans Redis.

Service de préférences et de politique

• Stocke et sert les préférences de canal par utilisateur, les opt-ins par catégorie, les heures de silence avec fuseau horaire, les paramètres par appareil, les listes de mise en sourdine/blocage, et les indicateurs de consentement légal (RGPD/CAN-SPAM).
• Le chemin de lecture est mis en cache dans Redis avec invalidation en écriture directe ; cible de recherche p99 inférieure à 5 ms. Source de vérité dans un magasin relationnel.
• Applique le plafonnement de fréquence (par exemple, max N push/heure par utilisateur) pour protéger l'expérience utilisateur et les quotas des fournisseurs.

Routeur / Répartiteur

• Mappe une livraison approuvée en éléments de travail spécifiques au canal. Décide « dans l'application + WebSocket uniquement si en ligne ; sinon push mobile » en utilisant le registre de connexion, et planifie des résumés par e-mail au lieu d'envois instantanés lorsque les préférences l'indiquent.

Passerelle en temps réel (couche WebSocket)

• Niveau d'état détenant des connexions WebSocket persistantes (solution de repli : Server-Sent Events, puis interrogation longue).
• À la connexion : authentifier, enregistrer (user_id, device_id) -> gateway_node_id dans le registre de connexion (Redis Cluster, TTL + rafraîchissement par battement de cœur), puis pousser tout le backlog non lu.
• À la livraison : le répartiteur recherche le nœud, envoie via un flux gRPC interne ou un canal Kafka/Redis Pub/Sub par nœud ; la passerelle écrit sur le socket et attend un accusé de réception du client.
• Battements de cœur toutes les 30 secondes ; les battements de cœur manqués suppriment l'entrée du registre et les notifications futures reviennent automatiquement au push mobile.

Travailleurs de canal

• Travailleur Push Mobile : regroupe vers APNs (HTTP/2 multiplexé, authentification par jeton) et FCM. Gère les limites de concurrence par fournisseur, le backoff exponentiel avec gigue, et supprime les jetons d'appareil invalides/non enregistrés du registre d'appareils.
• Travailleur Push Web : protocole Web Push avec clés VAPID et chiffrement de charge utile.
• Travailleur Email : rend les modèles, prend en charge les résumés instantanés, horaires ou quotidiens ; gère les rebonds/plaintes via les webhooks du fournisseur et maintient une liste de suppression.
• Tous les travailleurs sont des consommateurs idempotents indexés par notification_id et écrivent le statut terminal dans un sujet delivery.status.

Écrivain d'historique et Chemin de lecture

• Consommateur qui persiste les notifications et maintient les compteurs de non lus dans Redis (compteur faisant autorité, réconcilié périodiquement à partir du magasin).
• L'API de lecture sert les 100 dernières notifications du magasin d'historique, avec un cache Redis de la première page par utilisateur pour des lectures typiques inférieures à 10 ms.

Services de support

• Service de modèles : modèles versionnés et localisés avec interpolation de variables ; découple les changements de copie des déploiements de code.
• Registre d'appareils : jeton d'appareil, plateforme, version de l'application, locale, fuseau horaire, dernière connexion.
• Magasin de déduplication : Redis avec un TTL de 24h sur (producer_id, idempotency_key) pour que « au moins une fois » se comporte comme « effectivement une fois ».
• Planificateur : pour les notifications retardées/planifiées et les fenêtres de résumé (files d'attente par compartiment temporel dans des ensembles triés Redis ou un planificateur dédié comme une échelle de sujets de délai Kafka).
• DLQ + Relecteur : messages poison garés et rejouables après corrections.

4. MODÈLE DE DONNÉES ET CHOIX DE BASES DE DONNÉES

a) Historique des notifications — Cassandra (ou ScyllaDB / DynamoDB)
Table : notifications_by_user

• Clé de partition : user_id
• Clé de clustering : created_at DESC, notification_id
• Colonnes : type, actor_id(s), target_type, target_id, aggregated_count, preview_text, image_url, deep_link, read_at, channels_sent, created_at
• TTL : 90 jours ; l'application limite les lectures à 100 lignes.
  Justification : le modèle d'accès est une clé de partition unique et bien connue avec une tranche ordonnée par le temps — exactement le point fort de Cassandra. Elle offre une scalabilité d'écriture linéaire (nous avons besoin de 60 à 100 000 écritures/sec soutenues), une réplication sans maître multi-régions pour la disponibilité, une cohérence réglable (écritures QUORUM/LOCAL_QUORUM, lecture LOCAL_ONE pour le flux), et un TTL natif pour la rétention. Nous n'avons pas besoin de jointures ou de transactions multi-lignes ici, donc un magasin relationnel n'ajouterait que des difficultés de partitionnement et un risque d'amplification d'écriture.

b) Compteurs de non lus et première page « chaude » — Redis Cluster

• Compteur entier unread:{user_id} ; liste JSON mise en cache notif:page0:{user_id}.
  Justification : les compteurs sont lus à chaque ouverture d'application (QPS extrêmement élevé, faible valeur par lecture) et doivent être à la milliseconde près. Redis absorbe cela à moindre coût ; les compteurs Cassandra sont comparativement coûteux et sujets aux erreurs. Les compteurs sont réconciliés de manière asynchrone, donc la dérive se corrige d'elle-même.

c) Préférences utilisateur et jetons d'appareil — PostgreSQL (partitionné par user_id) avec cache en lecture directe Redis
Tables : 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).
Justification : ces données sont de faible volume, fortement lues, relationnelles (utilisateurs -> appareils -> paramètres par catégorie), et bénéficient des transactions et des contraintes pour la correction et l'auditabilité (les enregistrements de consentement ont un poids de conformité). Le volume est suffisamment faible (environ 100 millions de lignes) pour être facilement partitionné et mis en cache presque entièrement.

d) Registre de connexion — Redis Cluster

• conn:{user_id} -> ensemble de {device_id, gateway_node_id, connected_at}, TTL 90s rafraîchi par battement de cœur.
  Justification : éphémère, rotation extrêmement élevée, doit être rapide ; la durabilité n'est pas nécessaire car une entrée perdue dégrade gracieusement vers le fallback push.

e) Déduplication / idempotence — Redis avec TTL, sauvegardé par rien (la perte ne risque qu'un doublon rare).

f) Modèles et configuration — PostgreSQL + stockage d'objets pour les actifs, mis en cache en périphérie.

g) Analyse — événements diffusés de Kafka vers un lac de données (S3/Parquet) et un entrepôt (Snowflake/BigQuery) pour le reporting des taux de livraison, des taux d'ouverture et de latence ; ClickHouse pour les tableaux de bord opérationnels quasi en temps réel.

5. RECOMMANDATIONS DE LA PILE TECHNOLOGIQUE

• Langage/runtime : Go pour la passerelle, la passerelle en temps réel et les travailleurs (les goroutines et la faible mémoire par connexion conviennent à des millions de sockets) ; Java/Kotlin acceptable pour l'agrégation intensive par Kafka Streams.
• Messagerie : Apache Kafka (géré : MSK/Confluent) comme colonne vertébrale ; sujets distincts par canal et par classe de priorité. Kafka Streams ou Flink pour l'agrégation/coalescence fenêtrée.
• Transport en temps réel : WebSocket sur TLS avec SSE et fallbacks d'interrogation longue ; équilibrage de charge NLB/L4 avec vidage de connexion ; le routage collant n'est pas requis car le registre stocke l'identité du nœud.
• Mise en cache : Redis Cluster (ou Elasticache/MemoryDB) pour les compteurs, les préférences, le registre, la déduplication, les limites de débit.
• Magasins de données : Cassandra/ScyllaDB pour l'historique ; PostgreSQL (Aurora) pour les préférences/appareils ; S3 + entrepôt pour l'analyse.
• Fournisseurs de push : APNs, FCM, Web Push (VAPID) ; e-mail via SES avec SendGrid comme fournisseur secondaire derrière une couche d'abstraction de fournisseur pour le basculement.
• Infrastructure : Kubernetes avec HPA/KEDA évoluant sur le décalage du consommateur Kafka (pas seulement le CPU), maillage de services Envoy/Istio pour mTLS et les tentatives, Terraform pour l'IaC.
• Observabilité : traçage OpenTelemetry (ID de trace propagé de l'événement producteur à l'accusé de réception client), métriques Prometheus + Grafana, journaux structurés dans Loki/ELK, alertes PagerDuty sur les SLO.
• Bibliothèques de résilience : disjoncteurs et « bulkheads » par fournisseur externe, limiteurs de débit à jetons, backoff exponentiel avec gigue.

6. STRATÉGIES DE SCALABILITÉ, LATENCE ET DISPONIBILITÉ

Scalabilité

• Tous les composants sans état (API, diffusion, routeur, travailleurs) s'adaptent horizontalement ; le nombre de partitions Kafka est le plafond de parallélisme, donc provisionnez les partitions pour 5 à 10 fois le pic actuel dès le premier jour (la repartition est opérationnellement pénible).
• Mise à l'échelle automatique sur le décalage du consommateur avec KEDA afin qu'un pic 5x déclenche une mise à l'échelle en quelques secondes ; conservez un tampon chaud de 30 à 40 % de marge car la mise à l'échelle n'est pas instantanée.
• Partitionnement par user_id de manière cohérente entre Cassandra, Postgres et Redis afin que les données d'un seul utilisateur soient co-localisées et que l'atténuation des partitions chaudes soit uniforme.
• Voies prioritaires : les notifications interactives (DM, commentaire sur votre publication) utilisent un sujet de haute priorité avec des groupes de consommateurs dédiés ; la diffusion en bloc/marketing/célébrité utilise une voie à faible priorité limitée. Cela garantit le SLO de 2 secondes pour les notifications que les utilisateurs remarquent réellement.
• Gestion des célébrités/clés chaudes via la diffusion hybride push/pull décrite ci-dessus, plus des clés de partition salées pour les cibles extrêmement chaudes.

Faible latence (p99 inférieure à 2 secondes)

• Le chemin critique est intentionnellement court : ajout API -> Kafka -> diffusion -> succès du cache de préférences -> recherche dans le registre -> écriture WebSocket. Toutes les recherches sont dans Redis (moins de 5 ms) ; aucune écriture de base de données synchrone ne bloque la livraison.
• La persistance de l'historique et l'analyse sont asynchrones, hors du chemin de livraison.
• Producteurs Kafka optimisés avec linger.ms=5 et compression (lz4) pour équilibrer le regroupement et la latence ; les consommateurs utilisent la validation manuelle après traitement.
• Déploiement multi-régions avec les utilisateurs épinglés à la région la plus proche pour réduire le temps de trajet aller-retour ; les connexions WebSocket se terminent aux bords régionaux.
• Les fenêtres d'agrégation sont configurables par type et désactivées pour les types critiques en termes de latence comme les DM.
• Des sondes synthétiques continues mesurent la latence réelle de bout en bout par région et par canal.

Haute disponibilité (99,9 % et plus)

• Aucun point de défaillance unique : multi-AZ pour chaque niveau, Kafka RF=3 avec min.insync.replicas=2, écritures Cassandra RF=3 avec LOCAL_QUORUM, Postgres avec réplique de secours synchrone et basculement automatisé.
• Multi-régions actif-actif pour les niveaux temps réel et livraison ; Cassandra réplique de manière asynchrone entre les régions, Postgres utilise des répliques de lecture régionales avec une région d'écriture désignée.
• Dégradation gracieuse : si le chemin WebSocket est défaillant, retour au push mobile ; si le cache de préférences est en panne, retour à Postgres puis à des valeurs par défaut conservatrices ; si les écritures Cassandra échouent, continuer la livraison en temps réel et rejouer les écritures d'historique depuis Kafka par la suite.
• Tentatives avec backoff exponentiel plus gigue, tentatives plafonnées, puis DLQ avec alertes et un outil de relecture.
• Disjoncteurs par fournisseur externe afin qu'une panne APNs ne puisse pas épuiser les threads de travail et bloquer l'e-mail.
• Livraison au moins une fois plus déduplication notification_id côté serveur et client ; les clients dédupliquent également à la reconnexion lors de la relecture du backlog non lu.
• Pratiques de fiabilité : exercices de chaos/game day (tuer un nœud de passerelle et vérifier le fallback push), tests de charge à 5x le pic, déploiements blue-green et canary, drapeaux de fonctionnalités pour les interrupteurs par canal, rejet de la pression de la circulation de faible priorité avant la circulation de haute priorité.

7. Goulots d'étranglement et compromis

Goulots d'étranglement probables

• Fournisseurs tiers (APNs/FCM/e-mail) : le plafond le plus difficile, car le débit ne dépend pas de nous. Atténuer avec la mise en pool de connexions sur HTTP/2, le regroupement, les limiteurs de débit par fournisseur, le basculement multi-fournisseurs pour l'e-mail et le lissage basé sur des files d'attente des pics.
• Diffusion de célébrités : une seule publication peut générer des dizaines de millions de livraisons. Atténué par le push/pull hybride, les voies de diffusion en bloc limitées et l'agrégation.
• Niveau de connexion WebSocket : mémoire et descripteurs de fichiers par nœud, plus les reconnexions « thundering herd » après un déploiement ou un problème réseau. Atténuer avec des limites de noyau optimisées, une reconnexion échelonnée avec gigue et backoff exponentiel appliqué côté client, et un vidage lent des connexions pendant les déploiements.
• Clés chaudes Redis : clé d'agrégation d'une publication virale ou d'un compteur partagé. Atténuer avec le salage de clés, les caches locaux en mémoire avec des TTL courts et le partitionnement côté client.
• Amplification d'écriture Cassandra et pression de compaction à 100 000 écritures/sec. Atténuer avec la compaction par fenêtre temporelle (TWCS) adaptée aux données TTL de séries temporelles, et en ne stockant pas du tout les types de notifications de faible valeur dans l'historique.
• Désalignement des partitions Kafka si le partitionnement est basé sur une clé de faible cardinalité ; toujours partitionner par recipient_user_id sur le sujet de livraison.

Compromis explicites

• Au moins une fois plutôt qu'exactement une fois : exactement une fois entre des fournisseurs externes hétérogènes est impraticable et coûteux. Nous acceptons les doublons rares et les résolvons avec des clés d'idempotence et une déduplication côté client — moins cher et beaucoup plus disponible.
• Cohérence éventuelle pour les compteurs et l'historique plutôt que cohérence forte : un badge non lu momentanément erroné est acceptable ; une latence de plusieurs secondes pour le garantir ne l'est pas. Les travaux de réconciliation limitent la dérive.
• Persistance polyglotte plutôt qu'une seule base de données : cela augmente la surface opérationnelle (trois magasins de données plus Redis) mais chaque charge de travail obtient le bon moteur. Un seul cluster Postgres deviendrait le goulot d'étranglement à 1 milliard d'écritures/jour ; un seul cluster Cassandra rendrait les préférences et l'audit de consentement gênants.
• Diffusion basée sur le push pour la plupart des utilisateurs, basée sur le pull pour les célébrités : complexité de code accrue, mais c'est la seule façon d'éviter les tempêtes d'écriture illimitées.
• L'agrégation améliore l'expérience utilisateur et réduit considérablement le volume de livraison, mais ajoute jusqu'à une fenêtre de latence pour les types agrégables. Nous maintenons des fenêtres courtes et exemptons les DM.
• Le déploiement multi-régions actif-actif augmente le coût et introduit des subtilités de cohérence inter-régions, justifié par les cibles de disponibilité et de latence. Si le budget était limité, une posture mono-région avec secours à chaud répondrait toujours à 99,9 % mais avec un RTO plus long.
• Kafka plutôt qu'une file d'attente gérée plus simple (SQS) : plus de charge opérationnelle, mais nous avons besoin de relecture, de partitions ordonnées par clé, de plusieurs groupes de consommateurs indépendants et d'une rétention de 7 jours pour la récupération d'incidents.
• Stocker seulement les 100 dernières notifications avec un TTL de 90 jours échange la complétude de l'archivage contre le coût et la performance de lecture ; les données à long terme résident dans le lac d'analyse si jamais nécessaire.

8. PLAN DE DÉPLOIEMENT (PHASÉ)

Phase 1 : API d'ingestion + Kafka + écrivain d'historique + API de lecture (notifications dans l'application uniquement). Établit la colonne vertébrale durable.
Phase 2 : Passerelle en temps réel, registre de connexion, compteurs de non lus, livraison WebSocket avec fallback push.
Phase 3 : Travailleurs push mobile et push web, registre d'appareils, service de préférences et heures de silence.
Phase 4 : E-mail instantané + résumés, service de modèles, gestion de la suppression.
Phase 5 : Agrégation/coalescence, diffusion hybride de célébrités, plafonnement de fréquence.
Phase 6 : Multi-régions actif-actif, tests de chaos, validation de charge 5x, tableaux de bord SLO et budgets d'erreur.

9. INDICATEURS CLÉS ET SLO

• Latence p50/p95/p99 de bout en bout par canal (SLO : p99 inférieure à 2 secondes pour WebSocket).
• Taux de succès de livraison par canal ; taux d'erreurs des fournisseurs et taux d'invalidation de jetons.
• Décalage du consommateur Kafka par sujet (signal principal de mise à l'échelle automatique et de pagination).
• Nombre de connexions WebSocket, taux de rotation et taux d'accusé de réception.
• Dérive du compteur de non lus détectée par la réconciliation.
• Profondeur et âge de la DLQ.
• Disponibilité par API mesurée du point de vue du client, suivie par rapport à un budget d'erreur mensuel.

Architecture de haut niveau :

Le système est piloté par les événements. Les services de produits tels que le Service de suivi, le Service de publication, le Service de commentaires, le Service de réactions et le Service de messagerie directe publient des événements déclencheurs de notification sur un bus de messages durable. Un pipeline de notification consomme ces événements, les enrichit, applique les préférences utilisateur et les règles de déduplication, persiste les enregistrements de notification et achemine les tâches de livraison vers des agents de livraison spécifiques au canal pour les notifications websocket/web push, mobile push et e-mail en temps réel.

Flux principal :

1. Une action utilisateur se produit, par exemple l'utilisateur A aime la publication de l'utilisateur B.
2. Le service source écrit sa propre transaction métier, puis publie un événement de notification sur un courtier de messages en utilisant un modèle outbox ou un journal d'événements transactionnel.
3. L'ingestion de notifications valide l'événement, le normalise selon un schéma commun et lui attribue une clé d'idempotence.
4. La diffusion et le routage déterminent les destinataires, le type de notification, la priorité, l'éligibilité au canal et si le destinataire est en ligne.
5. Le stockage des notifications écrit la notification dans l'historique des notifications du destinataire.
6. La livraison en temps réel est tentée via des connexions websocket pour les utilisateurs web/application en ligne et des notifications push mobiles pour les appareils mobiles, le cas échéant.
7. La livraison par e-mail est mise en file d'attente séparément, généralement avec regroupement et priorité plus faible pour éviter de spammer les utilisateurs.
8. Le statut de livraison, les nouvelles tentatives, les échecs et les métriques sont suivis de manière asynchrone.

Estimation de l'échelle :

100 millions d'utilisateurs actifs par jour multipliés par 10 événements par jour équivalent à 1 milliard d'événements déclencheurs de notification par jour. Le taux d'événements moyen est d'environ 11 600 événements par seconde. La charge de pointe à 5x est d'environ 58 000 événements par seconde. La conception doit prévoir une diffusion interne plus importante car un événement peut notifier plusieurs destinataires, en particulier pour les commentaires, les mentions, les conversations de groupe ou les interactions en direct. Une cible initiale sûre pourrait être de 100 000 à 300 000 livraisons de notifications par seconde au pic, en fonction du comportement du produit.

Composants clés et responsabilités :

1. Passerelle API
   Accepte les requêtes API externes pour lire l'historique des notifications, marquer les notifications comme lues, mettre à jour les préférences de notification, enregistrer les appareils et ouvrir des connexions websocket. Gère l'authentification, la limitation du débit, le routage des requêtes et la protection de base contre les abus.

2. Producteurs d'événements
   Les services de produits existants génèrent des événements de domaine tels que UserFollowed, PostLiked, CommentCreated, UserMentioned, DirectMessageCreated et MessageReactionAdded. Les producteurs ne doivent pas appeler de manière synchrone les services de livraison de notifications, car cela couplerait la latence du produit à l'infrastructure de notification. Ils publient sur un bus d'événements durable.

3. Bus d'événements ou file d'attente de messages
   Un journal distribué tel qu'Apache Kafka ou Apache Pulsar est recommandé. Il offre un débit élevé, un stockage durable, une capacité de relecture, un partitionnement, des groupes de consommateurs et une gestion du contre-pression. Les sujets peuvent être séparés par famille d'événements ou par priorité, par exemple interactions sociales, messages directs, livraison de notifications haute, livraison de notifications normale, livraison de notifications par e-mail.

4. Service d'ingestion de notifications
   Consomme les événements bruts du produit, valide les schémas, filtre les notifications invalides/auto-générées le cas échéant, normalise les charges utiles des événements, génère des identifiants de notification et effectue des vérifications d'idempotence. Il enrichit également les événements avec des métadonnées légères telles que le nom de l'acteur, la référence de l'avatar de l'acteur, l'identifiant de la publication et le type d'objet cible. L'enrichissement lourd doit être minimisé ou effectué de manière asynchrone pour protéger la latence.

5. Service de diffusion (Fan-out Service)
   Détermine les destinataires et crée des tâches de notification par destinataire. Pour les événements un à un tels qu'un like, un suivi ou un message direct, la diffusion est simple. Pour les événements impliquant plusieurs destinataires, tels que les mentions, les messages de groupe ou les fils de commentaires, la diffusion peut produire de nombreux enregistrements de livraison. Il doit prendre en charge à la fois la diffusion à l'écriture (fan-out-on-write) et la diffusion à la lecture (fan-out-on-read) en fonction de l'échelle.

Approche recommandée :
Pour les notifications normales, utilisez la diffusion à l'écriture et stockez les enregistrements de notification par destinataire. Cela rend la récupération de l'historique rapide et permet les comptes de non lus.
Pour les entités à très forte diffusion, telles que les diffusions de célébrités ou les groupes massifs, utilisez une diffusion hybride : stockez un objet de notification partagé et matérialisez-le uniquement pour les utilisateurs actifs ou à la lecture.

6. Service de préférences et de politiques
   Stocke et évalue les préférences de notification utilisateur, les paramètres de confidentialité, les relations de mise en sourdine/blocage, les heures calmes, les autorisations de canal, la locale, le statut d'opt-in par e-mail et les paramètres spécifiques à la plateforme. Il renvoie l'éligibilité au canal et la priorité. Les préférences doivent être mises en cache de manière agressive.

7. Service de stockage des notifications
   Persiste l'historique et l'état des notifications. Il stocke les N dernières notifications, l'état non lu/lu, les horodatages, le type, l'acteur, les références d'entité et les métadonnées de rendu. Il prend en charge les requêtes telles que les 100 dernières notifications pour un utilisateur, le nombre de non lus, marquer comme lu, marquer tout comme lu et supprimer/masquer.

8. Passerelle de connexion en temps réel
   Maintient les connexions websocket ou server-sent events pour les utilisateurs web et d'application mobile en ligne. Il stocke la présence de la connexion dans un magasin de présence distribué. Les agents de livraison acheminent les notifications en temps réel vers le nœud de passerelle détenant la connexion active du destinataire. Pour les applications mobiles en arrière-plan, la livraison se rabat sur APNs/FCM.

9. Service de présence
   Suit si un utilisateur est en ligne, quels appareils sont connectés et quel nœud de passerelle possède chaque connexion. Les données de présence sont éphémères et doivent être stockées dans Redis Cluster ou un autre cache distribué à faible latence avec des battements de cœur TTL courts.

10. Services de livraison par canal
    Des agents distincts livrent les notifications par canal :
    Agent de notifications push mobiles : Envoie à APNs pour iOS et FCM pour Android. Gère l'invalidation des jetons, les erreurs du fournisseur, les échecs de nouvelle tentative et les clés de compression.
    Agent de notifications push web : Envoie des notifications push de navigateur via le protocole Web Push pour les utilisateurs ayant des abonnements de navigateur enregistrés.
    Agent Websocket : Envoie des notifications dans l'application à faible latence aux utilisateurs en ligne via la passerelle en temps réel.
    Agent E-mail : Envoie des e-mails via un fournisseur tel que SES, SendGrid ou un MTA interne. Il doit prendre en charge le regroupement, les modèles, les règles de désabonnement et les files d'attente à priorité plus faible.

11. Service de jetons d'appareil
    Stocke les jetons des appareils mobiles, les abonnements aux notifications push de navigateur, les métadonnées de l'appareil, la version de l'application, la plateforme, la locale et l'horodatage de la dernière connexion. Il gère la rotation des jetons et le nettoyage des jetons invalides.

12. Service de modèles et de localisation
    Rend le texte des notifications et les modèles d'e-mail en fonction du type de notification, de la locale, de l'acteur, des métadonnées de l'objet et des capacités du client. Préférer stocker des données de notification structurées et rendre au moment de la lecture pour l'historique dans l'application, tout en rendant les charges utiles finales au moment de la livraison pour les notifications push/e-mail.

13. Service de déduplication et d'agrégation
    Empêche le spam et les notifications dupliquées. Exemples : agréger « Alice et 12 autres personnes ont aimé votre publication » plutôt que d'envoyer 13 notifications push indépendantes. Utiliser des clés d'idempotence telles que event_type + actor_id + recipient_id + object_id + event_time_bucket. L'agrégation peut être effectuée avec des ensembles triés/compteurs Redis, puis persistée.

14. Métriques, journalisation et alertes
    Collecte la latence de bout en bout, le décalage de la file d'attente, le taux de succès de la livraison, le taux d'erreurs du fournisseur, le nombre de connexions websocket, le taux de création de notifications, le facteur de diffusion, la latence de la base de données, la précision du compte de non lus et le volume des files d'attente de nouvelles tentatives/lettres mortes.

Modèle de données :

1. Schéma d'événement de notification
   notification_event_id : identifiant unique global
   source_event_id : identifiant du service source
   event_type : follow, like, comment, direct_message, mention
   actor_user_id : utilisateur qui a causé l'événement
   recipient_user_ids ou référence de résolveur de destinataire
   target_type : post, comment, user, message, conversation
   target_id : identifiant de l'objet cible
   created_at : heure de l'événement
   metadata : JSON compact pour un contexte supplémentaire
   idempotency_key : clé stable pour la prévention des doublons
   priority : high, normal, low

2. Enregistrement d'historique de notification
   user_id : clé de partition du destinataire
   notification_id : identifiant unique triable par temps, par exemple Snowflake/UUIDv7
   notification_type
   actor_user_id ou résumé de l'acteur
   target_type
   target_id
   aggregation_key
   summary_text ou paramètres de rendu
   created_at
   read_at nullable
   seen_at nullable
   status : created, delivered, failed, hidden
   channels_attempted
   metadata

Pour le stockage de l'historique, utilisez une base de données à colonnes larges telle qu'Apache Cassandra, ScyllaDB ou DynamoDB. Partitionnez par user_id et regroupez par created_at descendant ou notification_id descendant. Cela correspond au modèle de requête principal : récupérer les 100 dernières notifications pour un utilisateur. Elle évolue horizontalement, prend en charge un débit d'écriture élevé et offre des lectures prévisibles à faible latence. Utilisez TTL ou une compaction en arrière-plan pour conserver l'historique récent selon les exigences du produit, tout en conservant au moins les 100 dernières. Si un « dernier 100 uniquement » strict est requis, maintenez un travail de troncature par utilisateur ou utilisez TTL plus une compaction périodique.

Exemple de table logique :
UserNotifications
clé de partition : user_id
clé de clustering : created_at descendant, notification_id
colonnes : type, actor_user_id, target_type, target_id, metadata, read_at, aggregation_key, status

3. Modèle de compte de non lus
   Utilisez Redis pour des lectures et écritures rapides du compte de non lus, sauvegardées par un stockage durable dans Cassandra/DynamoDB. Incrémentez lors de la création de la notification, décrémentez ou réinitialisez lors de la lecture/marquage de tout comme lu. Comme les compteurs peuvent dériver, réconciliez périodiquement à partir du stockage durable ou utilisez un modèle de marqueur de lecture.

Approche alternative de marqueur de lecture :
Stockez last_read_timestamp par utilisateur et traitez les notifications plus récentes que cela comme non lues. Cela rend le « marquer tout comme lu » peu coûteux. Pour l'état de lecture par notification, stockez read_at sur les enregistrements individuels. Une approche hybride est souvent la meilleure.

4. Préférences utilisateur
   Utilisez une base de données relationnelle telle que PostgreSQL ou MySQL pour les enregistrements de préférences durables, car les préférences nécessitent de la cohérence, des mises à jour structurées et des jointures/opérations d'administration occasionnelles. Mettez en cache les préférences fréquemment utilisées dans Redis ou Memcached. Pour une très grande échelle, partitionnez par user_id ou utilisez DynamoDB si l'organisation préfère une échelle clé-valeur gérée.
   Schéma de préférence :
   user_id
   notification_type
   channel : push, web, email, in_app
   enabled : boolean
   quiet_hours
   frequency : immediate, digest, never
   updated_at

5. Jetons d'appareil et abonnements push
   Utilisez DynamoDB, Cassandra ou un magasin relationnel partitionné indexé par user_id et device_id. Les recherches de jetons doivent être rapides et hautement disponibles. Stockez token_hash/token, platform, app_version, locale, enabled, last_seen_at et invalidated_at.

6. Données de présence
   Utilisez Redis Cluster avec TTL :
   user_id -> identifiants de connexion actifs, identifiants d'appareil, identifiants de nœud de passerelle, dernier heartbeat
   connection_id -> user_id, nœud de passerelle, expiration
   La présence peut être éventuellement cohérente car il ne s'agit que d'une optimisation pour la livraison en temps réel.

7. Statut de livraison et journaux d'audit
   Utilisez des sujets Kafka plus un magasin analytique moins coûteux tel que S3/stockage objet, ClickHouse, BigQuery ou Elasticsearch/OpenSearch pour le débogage opérationnel, l'analyse et le reporting de livraison. Ne placez pas les journaux de livraison à haut volume dans le magasin transactionnel principal, sauf si nécessaire.

Recommandations de pile technologique :

Courtier de messages : Kafka ou Pulsar pour le streaming d'événements durable, partitionné par recipient_user_id lorsque l'ordre par destinataire est important. Utilisez des sujets séparés pour l'ingestion, la diffusion, la livraison par canal, les nouvelles tentatives et les files d'attente de lettres mortes.

Bases de données :
Cassandra/ScyllaDB/DynamoDB pour l'historique des notifications.
PostgreSQL/MySQL ou DynamoDB pour les préférences utilisateur.
Redis Cluster pour la présence, le cache de compte de non lus, le cache à court terme d'idempotence, les limites de débit et les fenêtres d'agrégation.
Stockage objet plus base de données analytique pour les journaux et l'analyse historique.

Transport en temps réel :
WebSocket pour les notifications en temps réel dans l'application et sur le web. Server-Sent Events peut être utilisé pour la livraison unidirectionnelle uniquement sur le web, mais WebSocket est plus flexible pour les accusés de réception et les battements de cœur.

Fournisseurs de push :
APNs pour iOS, FCM pour Android, Web Push pour les navigateurs. Abstrayez les fournisseurs derrière un service de livraison push pour isoler le comportement spécifique au fournisseur.

E-mail :
Amazon SES, SendGrid, Mailgun ou infrastructure d'e-mail interne. Utilisez des files d'attente dédiées, des modèles, des listes de suppression et la digestion.

Calcul :
Services sans état sur Kubernetes ou un orchestrateur similaire. Mise à l'échelle horizontale des consommateurs basée sur le décalage de la file d'attente, le CPU et la latence de livraison. Utilisez un déploiement régional avec des équilibreurs de charge et la découverte de services.

Identifiants :
Utilisez UUIDv7, ULID ou des identifiants Snowflake pour les identifiants de notification triables. Assurez l'idempotence via source_event_id et des clés d'idempotence spécifiques à la notification.

Stratégie de mise à l'échelle :

1. Partitionnement
   Partitionnez les sujets Kafka par recipient_user_id pour l'ordre par utilisateur lorsque nécessaire. Pour les événements source avec un destinataire inconnu, partitionnez par entité source jusqu'à la diffusion, puis repartitionnez par destinataire. Partitionnez l'historique des notifications par user_id pour optimiser les requêtes de dernières notifications.

2. Mise à l'échelle horizontale
   Tous les services de pipeline doivent être sans état, à l'exception des passerelles et du stockage. Les consommateurs peuvent être mis à l'échelle en augmentant les partitions de sujet et les réplicas de travailleurs. Les passerelles en temps réel s'adaptent au nombre de connexions et à la bande passante.

3. Contre-pression
   Si les fournisseurs en aval ralentissent, les files d'attente absorbent les pics. Utilisez des files d'attente séparées par canal et par priorité afin que les retards d'e-mail n'affectent pas les messages directs ou les notifications dans l'application. Appliquez des limites de débit par utilisateur, par acteur, par type de notification et par fournisseur.

4. Mise en cache
   Mettez en cache les préférences, les jetons d'appareil, la présence, les modèles et les comptes de non lus. Utilisez des TTL courts pour les données qui changent fréquemment. Les échecs de cache ne doivent pas bloquer toute la livraison ; si les préférences sont temporairement indisponibles, échouez en toute sécurité selon les règles du produit, souvent en envoyant uniquement les enregistrements essentiels dans l'application et en différant les canaux externes.

5. Agrégation
   Réduisez le volume de diffusion et de notifications push en agrégeant les likes et les interactions similaires. Par exemple, stockez chaque événement de like si nécessaire pour l'analyse, mais envoyez une notification par publication par fenêtre de temps : « Alice, Bob et 10 autres personnes ont aimé votre publication. »

6. Diffusion hybride
   Pour les scénarios à forte diffusion, évitez d'écrire des millions de lignes immédiatement. Stockez un événement partagé et matérialisez les notifications pour les utilisateurs actifs d'abord, puis paresseusement pour les utilisateurs inactifs lorsqu'ils ouvrent l'application.

7. Déploiement multi-régions
   Déployez actif-actif ou actif-passif entre les régions. Pour une disponibilité de 99,9 %, l'actif-actif pour les passerelles en temps réel et les services sans état est recommandé, tandis que les magasins de données doivent utiliser au minimum la réplication multi-AZ. Le routage mondial des utilisateurs peut envoyer les utilisateurs vers la région saine la plus proche. Utilisez des clusters Kafka régionaux avec réplication ou un système de streaming multi-régions géré.

Stratégie de faible latence :

1. Gardez les services de produits découplés de la livraison des notifications. La publication d'événements doit être rapide et fiable.
2. Utilisez Kafka/Pulsar avec suffisamment de partitions et de consommateurs pour maintenir un faible décalage de file d'attente.
3. Utilisez Redis pour la recherche de présence et les décisions de routage.
4. Utilisez la livraison websocket pour les utilisateurs en ligne car elle évite la latence des fournisseurs de push tiers.
5. Persistez les enregistrements de notification avant ou en parallèle de la livraison en fonction des besoins de fiabilité. Une approche courante consiste à écrire d'abord l'historique, puis à livrer ; pour une latence ultra-faible, la livraison et le stockage peuvent se produire simultanément avec une nouvelle tentative idempotente.
6. Évitez les jointures synchrones coûteuses. Les événements doivent inclure suffisamment de métadonnées pour le rendu, ou utiliser des résumés d'utilisateurs/objets mis en cache.
7. Priorisez les messages directs et les notifications sensibles à la sécurité par rapport aux notifications sociales de faible valeur.

Fiabilité et haute disponibilité :

1. Messagerie durable
   Utilisez la réplication Kafka/Pulsar entre les zones de disponibilité. Les producteurs utilisent des accusés de réception et des nouvelles tentatives. Les consommateurs ne valident les offsets qu'après un traitement durable ou après avoir écrit une sortie idempotente.

2. Modèle Outbox
   Les services sources écrivent les modifications de domaine et les événements sortants de manière transactionnelle dans une table outbox. Un relais publie l'outbox sur Kafka. Cela évite la perte d'événements lorsqu'un service réussit son écriture en base de données mais échoue avant la publication.

3. Idempotence
   Chaque étape doit être idempotente. Les événements dupliqués sont attendus en raison des nouvelles tentatives. Utilisez source_event_id, notification_id et idempotency_key pour éviter les enregistrements d'historique dupliqués et les tentatives de push dupliquées lorsque cela est possible.

4. Politique de nouvelle tentative
   Les échecs transitoires sont dirigés vers des sujets de nouvelle tentative avec un backoff exponentiel et du jitter. Les échecs permanents, tels que les jetons push invalides, sont gérés en marquant les jetons comme invalides. Les messages corrompus sont dirigés vers des files d'attente de lettres mortes pour inspection.

5. Dégradation gracieuse
   Si le fournisseur d'e-mail est en panne, mettez en file d'attente l'e-mail et continuez les notifications dans l'application. Si les fournisseurs de push sont lents, livrez via websocket/dans l'application et retentez le push plus tard. Si le cache des préférences est indisponible, rabattez-vous sur la lecture des préférences durables ou sur des valeurs par défaut conservatrices. Si la présence est indisponible, sautez le websocket et fiez-vous au push/historique.

6. Réplication et sauvegardes
   Utilisez des bases de données multi-AZ, des sauvegardes régulières, la récupération à un instant T pour les magasins relationnels et des procédures de restauration testées. Pour Cassandra/ScyllaDB, utilisez un facteur de réplication de 3 entre les AZ et des paramètres de quorum appropriés aux compromis latence/fiabilité.

7. Surveillance et SLO
   Suivez la latence de bout en bout p50/p95/p99 depuis la création de l'événement source jusqu'à la réception par le client. Alertez sur le décalage de la file d'attente, les pics d'échec de livraison, la limitation du fournisseur, les partitions chaudes de la base de données, le taux de déconnexion websocket, la pression mémoire de Redis et les tempêtes de rééquilibrage des consommateurs.

API d'historique des notifications :

GET dernières notifications :
Le client demande les 100 dernières notifications. L'API Gateway authentifie l'utilisateur, l'API de notification interroge UserNotifications par user_id ordonné par created_at descendant, enrichit les champs d'affichage manquants depuis le cache et renvoie des enregistrements structurés.

Marquer la notification comme lue :
L'API met à jour read_at pour cette notification et ajuste le compte de non lus de manière idempotente.

Marquer tout comme lu :
Stocke last_read_timestamp pour l'utilisateur et met à jour de manière asynchrone les anciens enregistrements non lus. Cela évite les écritures synchrones volumineuses.

Goulots d'étranglement potentiels et compromis :

1. Explosion de la diffusion (Fan-out explosion)
   Problème : Certains événements peuvent notifier de nombreux utilisateurs, submergeant les files d'attente et le stockage.
   Atténuation : Diffusion hybride, files d'attente prioritaires, agrégation, limites de débit, matérialisation paresseuse.
   Compromis : La diffusion à la lecture réduit la charge d'écriture mais complexifie les lectures et peut augmenter la latence de lecture.

2. Utilisateurs et publications chauds
   Problème : Les célébrités ou les publications virales peuvent générer un volume de notifications énorme pour un destinataire ou un objet.
   Atténuation : Agréger les notifications par objet et par fenêtre de temps, partitionner les clés d'agrégation, supprimer les notifications répétées de faible valeur.
   Compromis : Les utilisateurs peuvent recevoir des notifications moins granulaires.

3. Limites des fournisseurs de push
   Problème : APNs/FCM/fournisseurs d'e-mail peuvent limiter ou échouer.
   Atténuation : Agents de fournisseur dédiés, limitation de débit adaptative, nouvelles tentatives, nettoyage des jetons, backoff spécifique au fournisseur.
   Compromis : La livraison push externe ne peut pas toujours respecter la cible de moins de 2 secondes ; la livraison websocket pour les utilisateurs en ligne est le chemin fiable à faible latence.

4. Volume d'écriture de la base de données
   Problème : Les écritures de notification par destinataire à grande échelle peuvent être coûteuses.
   Atténuation : Utiliser des magasins à colonnes larges optimisés pour l'écriture, regrouper les écritures, TTL, agrégation, diffusion hybride.
   Compromis : Les magasins à colonnes larges ont une flexibilité de requête limitée ; la conception doit correspondre aux modèles d'accès.

5. Exactitude du compte de non lus
   Problème : Les compteurs mis en cache peuvent dériver sous les nouvelles tentatives et les mises à jour de lecture concurrentes.
   Atténuation : Mises à jour idempotentes, marqueurs de lecture, réconciliation périodique.
   Compromis : Le compte exact de non lus est plus coûteux qu'un compte de non lus éventuellement cohérent.

6. Ordre
   Problème : Les notifications peuvent arriver dans le désordre en raison du traitement distribué.
   Atténuation : Utiliser des identifiants triables et ordonner par heure d'événement/identifiant de notification à la lecture. Partitionner par destinataire pour un ordre plus fort par utilisateur si nécessaire.
   Compromis : L'ordre global strict n'est ni pratique ni nécessaire.

7. Latence versus durabilité
   Problème : Écrire l'historique avant la livraison améliore la fiabilité mais ajoute de la latence.
   Atténuation : Utiliser un stockage rapide en région locale et paralléliser le stockage/la livraison après l'attribution de l'idempotence.
   Compromis : La livraison parallèle peut brièvement afficher une notification push avant qu'elle n'apparaisse dans l'historique si le stockage est retardé.

8. Complexité de l'évaluation des préférences
   Problème : Les vérifications de préférences par événement peuvent être coûteuses au pic.
   Atténuation : Mettre en cache les préférences, pré-calculer les paramètres effectifs et invalider le cache lors des changements de préférences.
   Compromis : Les changements de préférences peuvent prendre quelques secondes à se propager, sauf si une cohérence forte est requise.

Résumé de la conception finale recommandée :

Utiliser une architecture pilotée par les événements avec Kafka/Pulsar comme colonne vertébrale, des services d'ingestion/diffusion/routage sans état, Cassandra/ScyllaDB/DynamoDB pour l'historique des notifications par utilisateur, Redis pour la présence et les caches chauds, des passerelles websocket pour la livraison en ligne en moins de 2 secondes, APNs/FCM/Web Push pour les notifications de plateforme, et un pipeline de livraison d'e-mails séparé. Le système doit être scalable horizontalement, partitionné principalement par user_id, résilient grâce à des files d'attente durables et un traitement idempotent, et optimisé pour une faible latence grâce à la mise en cache, au routage basé sur la présence en ligne, aux files d'attente prioritaires et à l'agrégation. Cette conception répond aux exigences fonctionnelles, prend en charge les 1 milliard d'événements quotidiens attendus avec des pics de 5x, et offre une voie pratique vers une disponibilité de 99,9 % avec une dégradation gracieuse en cas de défaillances partielles.