Concevoir un service de notifications évolutif

Un service de notification évolutif doit être construit comme une plateforme asynchrone et pilotée par les événements qui sépare l'ingestion des événements, l'évaluation des préférences, la persistance des notifications, la livraison spécifique au canal et le suivi de la livraison. Le principe de conception le plus important est que les systèmes de produits sources, tels que les suivis, les likes, les commentaires et les messages directs, ne doivent pas appeler de manière synchrone les fournisseurs de notifications push mobiles, les fournisseurs d'e-mails ou les appareils des utilisateurs. Ils doivent publier des événements durables dans une couche de messagerie, et la plateforme de notification doit traiter ces événements indépendamment avec de fortes garanties de nouvelle tentative et d'idempotence. À un niveau élevé, l'architecture contient ces composants : producteurs d'événements, une API d'ingestion, un journal d'événements durable, des processeurs de notifications, un service de préférences utilisateur, un service de modèles et de personnalisation, un magasin de notifications, des files d'attente de diffusion par canal, des workers de livraison spécifiques au canal, des intégrations de fournisseurs tiers, une passerelle en temps réel pour la livraison dans l'application, et une infrastructure d'observabilité/de nouvelle tentative. Les services de produits génèrent des événements de notification lorsque des actions visibles par l'utilisateur se produisent. Par exemple, le service de graphe social émet un événement de nouveau follower, le service de publication émet un événement de like ou de commentaire, et le service de messagerie émet un événement de message direct. Chaque événement contient un ID d'événement, un type d'événement, un ID d'utilisateur acteur, un ID d'utilisateur destinataire ou un ensemble de destinataires, un ID d'objet, un horodatage de création et les métadonnées nécessaires au rendu. Les producteurs envoient ces événements à une API d'ingestion de notifications ou directement à un bus de messages durable. L'API d'ingestion valide le schéma, authentifie le producteur, attribue ou vérifie une clé d'idempotence, et écrit l'événement dans le journal durable avant d'accuser réception au producteur. Cela évite la perte de notifications si les processeurs en aval échouent. Pour le backbone de messagerie durable, j'utiliserais Apache Kafka, Amazon MSK, Google Pub/Sub ou Pulsar. Kafka/Pulsar conviennent bien car ils offrent un débit élevé, un ordonnancement partitionné, une rétention, une relecture, des groupes de consommateurs et un stockage durable. À 50 000 requêtes de notification par seconde, le flux d'événements doit être partitionné par ID d'utilisateur destinataire pour l'ordonnancement au niveau de l'utilisateur si nécessaire, ou par ID d'événement lorsque l'ordonnancement strict par utilisateur est moins important. Le partitionnement par destinataire permet d'éviter les notifications dans l'application dans le désordre pour un seul utilisateur, mais il peut créer des partitions chaudes pour les comptes de célébrités ou les événements de groupe. Pour les cas de diffusion à grande échelle, où un événement produit des notifications à des millions de followers, un service de diffusion distinct doit diviser les destinataires en lots et publier des tâches de notification dérivées par destinataire sur de nombreuses partitions. Les processeurs de notifications consomment les événements bruts du journal d'événements durable. Leurs responsabilités sont de déterminer les destinataires, de récupérer les préférences utilisateur, d'appliquer les limites de débit et les heures de silence, de dédupliquer les événements, de générer des enregistrements de notification spécifiques au canal et de publier des tâches de livraison. Pour les événements directs comme un commentaire sur la publication d'un utilisateur, l'ensemble des destinataires est petit. Pour les événements de diffusion tels qu'une célébrité qui publie, le processeur doit éviter de tout diffuser de manière synchrone. Il doit créer une tâche de diffusion et traiter les destinataires par fragments, en utilisant des lectures par lots du magasin de graphes sociaux. Cela évite qu'un événement très volumineux ne bloque le chemin à faible latence pour les notifications normales. Le service de préférences utilisateur stocke la configuration, comme si un utilisateur souhaite des notifications push, dans l'application ou par e-mail pour les likes, les commentaires, les followers et les messages directs. Les préférences doivent être stockées dans une base de données hautement disponible telle que DynamoDB, Cassandra, ScyllaDB ou une base de données relationnelle sharding. Le modèle d'accès est principalement une recherche clé-valeur par ID utilisateur et type de notification, donc un magasin clé-valeur distribué ou à colonnes larges est approprié. Pour respecter la cible de latence de 2 secondes, les préférences doivent également être mises en cache dans Redis, Memcached ou un cache local en mémoire avec des TTL courts. Les mises à jour de préférences sont écrites dans la source de vérité de la base de données et propagées aux caches par des événements d'invalidation. Le compromis est que la fraîcheur du cache peut faire qu'une préférence récemment modifiée prenne quelques secondes à s'appliquer ; si une cohérence stricte des préférences est requise, les processeurs peuvent lire directement dans la base de données en cas de cache manqué ou pour les utilisateurs récemment mis à jour. Le service de modèles et de personnalisation rend le contenu des notifications. Il mappe les types d'événements à des modèles tels que « Alex a aimé votre publication » ou « Maya a commenté : ... ». Il gère la localisation, les liens profonds, les URL d'images et les contraintes de charge utile spécifiques au canal. Les définitions de modèles peuvent être stockées dans une base de données de configuration et mises en cache de manière agressive car elles changent peu fréquemment. Le rendu doit avoir lieu avant la publication des tâches de livraison afin que chaque tâche soit autonome et puisse être retentée en toute sécurité. Le magasin de notifications est la source de vérité pour les notifications dans l'application visibles par l'utilisateur et l'état de livraison. Un bon choix est Cassandra, DynamoDB, ScyllaDB ou un autre magasin horizontalement évolutif partitionné par ID d'utilisateur destinataire et trié par horodatage de notification. Le modèle d'accès principal est « récupérer les dernières notifications pour l'utilisateur X », donc la table peut utiliser recipient_user_id comme clé de partition et created_at ou notification_id comme clé de tri. Le service écrit un enregistrement de notification dans l'application avant ou de manière atomique avec la publication de la tâche de livraison dans l'application. Les enregistrements incluent l'ID de notification, le destinataire, le type, le contenu, le statut, l'état lu/non lu, les horodatages et la clé de déduplication. Ce magasin garantit que même si la livraison WebSocket échoue, l'utilisateur peut toujours voir la notification en ouvrant l'application. Après l'application des préférences et des modèles, le processeur publie des tâches dans des files d'attente de canaux distinctes : file d'attente push, file d'attente dans l'application et file d'attente e-mail. La séparation des files d'attente est importante car chaque canal a des caractéristiques de latence et de fiabilité différentes. Les files d'attente push et dans l'application sont sensibles à la latence et doivent être provisionnées pour un débit élevé avec un minimum de backlog. L'e-mail est moins sensible à la latence et peut tolérer des délais plus longs, le throttling des fournisseurs et le traitement par lots. Des files d'attente distinctes empêchent également un fournisseur d'e-mails lent d'affecter la livraison push. Les workers de livraison push consomment à partir de la file d'attente push et envoient des notifications à Apple Push Notification service, Firebase Cloud Messaging ou d'autres fournisseurs de notifications push mobiles. Les jetons d'appareil sont stockés dans un registre d'appareils indexé par ID utilisateur, avec le jeton, la plateforme, la version de l'application, la locale et l'horodatage de la dernière connexion. Le registre peut utiliser un magasin clé-valeur distribué et mettre en cache les jetons actifs. Les workers push doivent gérer les réponses des fournisseurs, supprimer les jetons invalides, retenter les échecs transitoires avec un backoff exponentiel et enregistrer les tentatives de livraison. Les accusés de réception des fournisseurs push ne garantissent pas que l'utilisateur a vu la notification, seulement que le fournisseur l'a acceptée, donc le système doit distinguer l'acceptation du fournisseur de la réception réelle par l'utilisateur. La livraison dans l'application a deux chemins. Premièrement, la notification est persistée dans le magasin de notifications. Deuxièmement, un worker de livraison dans l'application l'envoie aux appareils connectés de l'utilisateur via une passerelle en temps réel. La passerelle peut être implémentée à l'aide de WebSockets, de flux HTTP/2 ou d'une infrastructure de connexion persistante de type push mobile. Les nœuds de passerelle maintiennent l'état de connexion de l'utilisateur en mémoire et publient des informations de présence à un service de présence distribué. Une couche de routage ou une carte de présence basée sur NATS/Redis indique au worker dans l'application quel nœud de passerelle possède actuellement la connexion d'un utilisateur. Si l'utilisateur est hors ligne ou si l'envoi de la passerelle échoue, aucune notification n'est perdue car la notification persistée sera récupérée via l'API de la boîte de réception des notifications de l'application lors de la prochaine session. Pour une faible latence, les nœuds de passerelle doivent être déployés régionalement à proximité des utilisateurs et la file d'attente dans l'application doit être traitée par des workers dans la même région si possible. Les workers de livraison d'e-mails consomment à partir de la file d'attente d'e-mails et envoient via des fournisseurs tels que SES, SendGrid ou Mailgun. Ils doivent prendre en charge le basculement du fournisseur, la gestion des rebonds, les listes de suppression, la conformité de désabonnement et les limites de débit par fournisseur. Les notifications par e-mail peuvent être traitées par lots ou regroupées pour les types d'événements à faible priorité comme les likes, tandis que les messages directs ou les événements liés à la sécurité peuvent être envoyés immédiatement. Comme l'e-mail est plus lent et plus coûteux, les préférences utilisateur et la limitation du débit sont particulièrement importantes. La fiabilité est assurée par des écritures durables, un traitement au moins une fois, l'idempotence, les nouvelles tentatives et les files d'attente de lettres mortes. La couche d'ingestion n'accuse réception aux producteurs qu'après que l'événement a été écrit de manière durable dans Kafka/Pulsar. Les consommateurs ne valident les offsets qu'après avoir écrit avec succès les enregistrements de notification et publié les tâches de canal en aval. Comme les nouvelles tentatives peuvent créer des doublons, chaque événement et notification doit avoir des clés d'idempotence stables. Par exemple, une clé de notification de like pourrait être recipient_id + actor_id + post_id + event_type, tandis qu'une clé de notification de commentaire pourrait inclure comment_id. Le magasin de notifications impose l'unicité sur cette clé, ou les processeurs effectuent des écritures conditionnelles. Les workers de livraison doivent également utiliser des ID de tentative et des transitions d'état idempotentes afin que les tâches dupliquées ne créent pas d'enregistrements dans l'application dupliqués ou d'e-mails dupliqués lorsque cela est évitable. Le système garantit une livraison au moins une fois, pas une livraison exactement une fois, donc les clients doivent également dédupliquer par ID de notification. Les files d'attente de lettres mortes sont nécessaires pour les messages empoisonnés, les événements malformés, les échecs répétés du fournisseur ou les enregistrements qui ne peuvent pas être rendus. Un outil de relecture doit permettre aux opérateurs de corriger les problèmes et de retraiter les événements à partir du journal durable d'origine ou de la file d'attente de lettres mortes. La rétention de Kafka doit être suffisamment longue pour permettre la récupération opérationnelle, par exemple plusieurs jours. Les métadonnées critiques et l'état de livraison doivent également être persistés dans la base de données de notification pour l'auditabilité. Pour répondre à l'exigence d'échelle de 100 millions d'utilisateurs actifs quotidiens et 50 000 requêtes de notification par seconde, tous les services majeurs doivent être horizontalement évolutifs et sans état si possible. Les API d'ingestion s'adaptent derrière des équilibreurs de charge. Les sujets Kafka/Pulsar sont suffisamment partitionnés pour supporter le débit de pointe et le parallélisme des consommateurs. Les processeurs et les workers de livraison s'exécutent dans des groupes d'autoscaling ou des déploiements Kubernetes et s'adaptent en fonction du décalage de la file d'attente, du CPU, de la latence du fournisseur et du taux de requêtes. Les bases de données sont partitionnées par ID utilisateur pour répartir la charge. Les problèmes de clé chaude doivent être gérés avec des tâches de diffusion sharding, une gestion spéciale des utilisateurs célèbres et une backpressure. Pour une diffusion extrêmement large, le système peut utiliser une diffusion pull pour les notifications à faible priorité : au lieu d'écrire une notification par follower immédiatement, il stocke l'événement une fois et le matérialise lorsqu'un utilisateur ouvre l'application. Cela réduit l'amplification des écritures mais augmente la complexité des lectures et peut ne pas convenir aux messages directs ou aux commentaires. La cible de latence de 2 secondes pour 99 % des notifications push et dans l'application est atteinte en maintenant le chemin critique court : producteur vers journal durable, recherche de préférences du processeur depuis le cache, écriture de l'enregistrement de notification, publication dans la file d'attente du canal, et livraison immédiate par des workers chauds. Les workers push et dans l'application doivent être surprovisionnés pour la charge de pointe, et les files d'attente doivent utiliser des voies prioritaires afin que les messages directs et les commentaires soient traités avant les likes à faible priorité. Le déploiement régional réduit la latence réseau. Pour les utilisateurs dans plusieurs régions, le routage peut être basé sur la région d'origine du destinataire, avec une réplication inter-régions pour la reprise après sinistre. La conception doit mesurer la latence de bout en bout, de la création de l'événement à l'acceptation du fournisseur ou à l'envoi de la passerelle, et non pas seulement le temps de traitement interne. L'observabilité est essentielle. La plateforme doit suivre le taux de requêtes, le décalage de la file d'attente par partition, la latence de traitement, le taux de réussite du cache de préférences, les échecs de création de notifications, les taux d'erreur des fournisseurs, les nombres de nouvelles tentatives, le volume de lettres mortes, le succès de la livraison WebSocket, la latence d'acceptation du fournisseur push, et la latence p50/p95/p99 de bout en bout. Le traçage distribué doit transporter l'ID d'événement d'origine à travers chaque composant. Des alertes doivent se déclencher en cas de croissance du décalage de la file d'attente, d'échecs élevés, de throttling du fournisseur, de latence d'écriture de base de données et de SLO de latence manqués. Il existe plusieurs compromis. Kafka ou Pulsar ajoutent une complexité opérationnelle mais fournissent la durabilité, la relecture et le débit nécessaires à une livraison au moins une fois à cette échelle. Cassandra ou DynamoDB offrent une évolutivité et une disponibilité d'écriture élevées mais une capacité de requête ad hoc limitée, donc les analyses doivent être envoyées à un entrepôt de données séparé. La mise en cache des préférences améliore la latence mais introduit des problèmes de cohérence de courte durée. La livraison au moins une fois est beaucoup plus simple et plus fiable que la livraison exactement une fois, mais le système doit tolérer les doublons en utilisant des clés d'idempotence et une déduplication côté client. La diffusion à l'écriture donne des lectures rapides de la boîte de réception mais peut être coûteuse pour les événements à fort nombre de followers ; la diffusion à la lecture économise les écritures mais complique le classement et la matérialisation au moment de la lecture. Un modèle hybride est généralement le meilleur : diffusion à l'écriture pour les notifications directes, importantes et de volume normal, et diffusion à la lecture ou diffusion par lots pour les événements massifs à faible priorité. En résumé, le service doit utiliser une architecture événementielle durable avec des flux de messages partitionnés, des processeurs sans état, des recherches de préférences mises en cache, un stockage persistant des notifications, des files d'attente de canaux séparées, des workers spécifiques aux canaux et des mécanismes solides de nouvelle tentative/idempotence. Cette conception s'adapte horizontalement à 50 000 requêtes de notification par seconde, maintient la livraison push et dans l'application dans la cible p99 de 2 secondes grâce à la mise en cache et aux files d'attente à faible latence, et garantit que les notifications ne sont pas perdues en persistant les événements et les enregistrements de notification avant d'accuser réception des progrès.

## Architecture d'un Service de Notification Évolutif ### Vue d'ensemble du système Le service de notification est conçu comme un système distribué et piloté par les événements, qui traite les notifications de manière asynchrone pour gérer 50 000 requêtes par seconde avec une latence inférieure à 2 secondes pour 99 % des livraisons. L'architecture suit un modèle de microservices avec une séparation claire des responsabilités. ### Architecture de haut niveau ``` Sources d'événements → Passerelle API → Service de notification → File d'attente de messages → Travailleurs de livraison ↓ Service de préférences ↓ Couche de cache (Redis) ↓ Base de données (PostgreSQL) ``` ### Composants clés #### 1. Passerelle API - **Responsabilité :** Point d'entrée pour toutes les requêtes de notification. Gère la limitation du débit, l'authentification et la validation des requêtes. - **Technologie :** NGINX ou passerelle API AWS - **Raisonnement :** Fournit un point d'entrée unique, permet de limiter les requêtes pour éviter la surcharge et distribue le trafic entre les services backend. #### 2. Service de notification (Traitement principal) - **Responsabilité :** Reçoit les événements de notification, les valide, les enrichit avec les préférences de l'utilisateur et les publie dans la file d'attente de messages. - **Technologie :** Microservice sans état (Node.js, Go ou Java) - **Fonctionnalités clés :** - Valide la charge utile de notification - Récupère les préférences de l'utilisateur depuis le cache - Détermine les canaux de notification (push, in-app, e-mail) en fonction des paramètres de l'utilisateur - Publie les notifications enrichies dans la file d'attente de messages - **Évolutivité :** Évolutif horizontalement ; plusieurs instances derrière un équilibreur de charge #### 3. File d'attente de messages (Bus d'événements) - **Technologie :** Apache Kafka ou AWS SQS/SNS - **Raisonnement :** - Découple la génération de notifications de la livraison - Fournit la durabilité et la capacité de relecture pour une garantie de livraison au moins une fois - Permet le traitement parallèle des notifications - Gère les pics de trafic en mettant en mémoire tampon les requêtes - **Configuration :** Plusieurs partitions (par exemple, 100-200) pour permettre la consommation parallèle - **Structure des sujets :** Sujets distincts pour les notifications push, in-app et par e-mail pour permettre une mise à l'échelle indépendante #### 4. Service de préférences - **Responsabilité :** Gère les préférences et les paramètres de notification de l'utilisateur. - **Technologie :** Microservice avec backend PostgreSQL - **Fonctionnalités :** - Stocke les préférences de l'utilisateur (types de notification, canaux, limites de fréquence) - Fournit une API permettant aux utilisateurs de mettre à jour leurs préférences - Met en cache les préférences dans Redis pour un accès rapide - **Évolutivité :** Service fortement axé sur la lecture ; la mise en cache réduit considérablement la charge de la base de données #### 5. Couche de cache - **Technologie :** Cluster Redis - **Objectif :** - Met en cache les préférences de l'utilisateur (TTL : 1 heure) - Met en cache les jetons d'appareil de l'utilisateur pour les notifications push - Stocke les compteurs de limitation de débit - Réduit les requêtes de base de données de plus de 90 % - **Raisonnement :** Latence inférieure à la milliseconde pour les recherches de préférences #### 6. Travailleurs de livraison - **Travailleur de notification push :** - Consomme à partir du sujet push - S'intègre avec FCM (Firebase Cloud Messaging) et APNs (Apple Push Notification service) - Gère la gestion des jetons d'appareil et le nettoyage des jetons invalides - Implémente un backoff exponentiel pour les nouvelles tentatives - **Travailleur de notification in-app :** - Consomme à partir du sujet in-app - Stocke les notifications dans une base de données de séries temporelles (par exemple, Cassandra ou ClickHouse) - Publie vers des serveurs WebSocket pour une livraison en temps réel - Maintient le statut de notification lu/non lu - **Travailleur de notification par e-mail :** - Consomme à partir du sujet e-mail - Regroupe les e-mails pour plus d'efficacité - S'intègre avec le service d'e-mail (SendGrid, AWS SES) - Implémente la limitation du débit pour éviter les filtres anti-spam #### 7. Serveur WebSocket - **Responsabilité :** Maintient des connexions persistantes avec les clients mobiles et web pour les notifications in-app en temps réel. - **Technologie :** Node.js avec Socket.io ou Go avec gorilla/websocket - **Évolutivité :** Serveurs sans état ; utilise la publication/souscription Redis pour la communication inter-serveurs - **Solution de repli :** Long polling HTTP pour les clients qui ne prennent pas en charge WebSocket #### 8. Stockage de notifications (Base de données de séries temporelles) - **Technologie :** Cassandra ou ClickHouse - **Objectif :** Stocke toutes les notifications pour l'audit, l'analyse et l'historique des notifications de l'utilisateur - **Raisonnement :** Optimisé pour les charges de travail à forte écriture et les requêtes par plage de temps - **Rétention :** 90 jours d'historique des notifications #### 9. Registre des appareils utilisateur - **Technologie :** Redis + PostgreSQL - **Objectif :** Maintient la correspondance entre les utilisateurs et leurs appareils et jetons push - **Fonctionnalités :** - Suit l'enregistrement/désenregistrement des appareils - Stocke les métadonnées de l'appareil (OS, version de l'application) - Gère le rafraîchissement et l'invalidation des jetons ### Flux de données 1. **Ingestion des événements :** Les sources d'événements (actions utilisateur, événements système) envoient des requêtes de notification à la passerelle API 2. **Validation et enrichissement :** Le service de notification valide la charge utile et récupère les préférences de l'utilisateur depuis le cache 3. **Détermination du canal :** En fonction des préférences, la notification est acheminée vers le sujet approprié (push, in-app, e-mail) 4. **Mise en file d'attente :** La file d'attente de messages met en mémoire tampon les notifications et assure la durabilité 5. **Livraison :** Des travailleurs spécialisés consomment à partir des sujets et livrent via les canaux respectifs 6. **Accusé de réception :** Les travailleurs de livraison confirment la livraison réussie et mettent à jour le statut de la notification ### Répondre aux exigences #### Évolutivité (50 000 req/sec) - **Mise à l'échelle horizontale :** Tous les composants sont sans état et évolutifs horizontalement - **Partitionnement de la file d'attente de messages :** Sujets Kafka partitionnés sur plusieurs courtiers ; chaque partition peut gérer environ 500 à 1000 req/sec - **Partitionnement de la base de données :** Données utilisateur partitionnées par user_id pour répartir la charge - **Stratégie de mise en cache :** Redis met en cache les données fréquemment consultées, réduisant les requêtes de base de données de plus de 90 % - **Équilibrage de charge :** La passerelle API distribue le trafic entre les instances du service de notification #### Faible latence (99 % en 2 secondes) - **Traitement asynchrone :** Les notifications sont traitées de manière asynchrone ; l'API renvoie immédiatement après la mise en file d'attente - **Mise en cache :** Préférences utilisateur mises en cache dans Redis (accès inférieur à la milliseconde) - **Intégration directe :** Les travailleurs push s'intègrent directement avec FCM/APNs sans sauts intermédiaires - **WebSocket pour in-app :** Livraison en temps réel via des connexions persistantes - **Optimisation :** Traitement par lots pour les notifications par e-mail (acceptable pour le cas d'utilisation des e-mails) - **Surveillance :** La latence est suivie par composant ; alertes en cas de dégradation #### Fiabilité (Livraison au moins une fois) - **Durabilité de la file d'attente de messages :** Kafka réplique les messages entre les courtiers (facteur de réplication : 3) - **Files d'attente persistantes :** Les messages sont stockés sur disque avant l'accusé de réception - **Idempotence :** Les notifications incluent des identifiants uniques ; les travailleurs implémentent un traitement idempotent - **Logique de nouvelle tentative :** Les livraisons échouées sont retentées avec un backoff exponentiel (max 5 tentatives sur 24 heures) - **File d'attente de lettres mortes (DLQ) :** Les notifications échouées après le nombre maximal de tentatives sont déplacées vers la DLQ pour une enquête manuelle - **Surveillance et alertes :** Des tableaux de bord en temps réel suivent les taux de réussite de livraison ; alertes en cas d'échec - **Sauvegarde et récupération :** Sauvegardes régulières des données de préférences et de notification ; procédures de reprise après sinistre #### Personnalisation - **Service de préférences :** Service dédié gère les paramètres de notification de l'utilisateur - **Contrôles granulaires :** Les utilisateurs peuvent désactiver les notifications par type (j'aime, commentaires, suivis) et par canal - **Limites de fréquence :** Prise en charge des options de résumé quotidien/hebdomadaire - **Heures de silence :** Les utilisateurs peuvent définir des heures de silence (par exemple, pas de notifications push de 22h à 8h) - **Invalidation du cache :** Les modifications de préférences invalident le cache immédiatement pour un effet en temps réel ### Choix technologiques et compromis | Composant | Technologie | Raisonnement | Compromis | |-----------|-----------|-----------|-----------| | File d'attente de messages | Kafka | Débit élevé, durabilité, capacité de relecture | Complexité opérationnelle, nécessite une gestion de cluster | | Cache | Cluster Redis | Latence inférieure à la milliseconde, prend en charge les structures de données complexes | Limité par la mémoire, nécessite des politiques d'éviction prudentes | | DB de préférences | PostgreSQL | Conformité ACID, requêtes complexes, écosystème mature | Limites de mise à l'échelle verticale ; nécessite des répliques de lecture | | Stockage de notifications | Cassandra | Optimisé pour l'écriture, distribué, gère les données de séries temporelles | Cohérence éventuelle, modèle opérationnel complexe | | Intégration Push | FCM/APNs | Norme de l'industrie, haute fiabilité | Dépendance vis-à-vis du fournisseur, limites de débit par fournisseur | | WebSocket | Socket.io/gorilla | Communication en temps réel, prise en charge de la solution de repli | Surcharge mémoire par connexion, nécessite des sessions persistantes | ### Considérations opérationnelles #### Surveillance et Observabilité - **Métriques :** Débit de notification, percentiles de latence (p50, p95, p99), taux de réussite de livraison - **Journalisation :** Journalisation structurée avec des ID de corrélation pour le traçage de bout en bout - **Traçage distribué :** Jaeger ou Zipkin pour la visualisation du flux de requêtes - **Alertes :** Intégration PagerDuty pour les pannes critiques #### Déploiement et mise à l'échelle - **Conteneurisation :** Conteneurs Docker pour tous les services - **Orchestration :** Kubernetes pour la mise à l'échelle et le déploiement automatisés - **Mise à l'échelle automatique :** Horizontal Pod Autoscaler basé sur la profondeur de la CPU/mémoire et de la file d'attente - **Déploiement Blue-Green :** Déploiements sans interruption pour les mises à jour de service #### Optimisation des coûts - **Capacité réservée :** Courtiers Kafka et instances de base de données sur des instances réservées - **Stockage hiérarchisé :** Données chaudes dans Redis, données tièdes dans PostgreSQL, données froides dans S3 - **Traitement par lots :** Notifications par e-mail regroupées pour réduire les appels API - **Limites de ressources :** Limites de débit par utilisateur pour éviter l'épuisement des ressources ### Goulots d'étranglement potentiels et atténuation 1. **Goulot d'étranglement de la base de données :** Recherches de préférences - Atténuation : Mise en cache Redis avec TTL de 1 heure ; répliques de lecture pour PostgreSQL 2. **Goulot d'étranglement de la file d'attente de messages :** Débit Kafka - Atténuation : Augmenter le nombre de partitions ; mettre à niveau le matériel des courtiers ; utiliser la compression 3. **Limites de débit des services push :** Limites FCM/APNs - Atténuation : Implémenter la mise en file d'attente des requêtes ; regrouper les requêtes ; utiliser plusieurs comptes de service 4. **Limites de connexion WebSocket :** Limites par serveur de connexion - Atténuation : Mise à l'échelle horizontale ; pool de connexions ; équilibrage de charge entre les serveurs ### Conclusion Cette architecture fournit un service de notification évolutif, fiable et à faible latence, capable de gérer 50 000 requêtes par seconde tout en maintenant une livraison inférieure à 2 secondes pour 99 % des notifications. L'utilisation du traitement asynchrone, des files d'attente de messages et de la mise en cache garantit à la fois les performances et la fiabilité. La conception modulaire permet une mise à l'échelle indépendante des composants en fonction de la demande, et la surveillance complète assure la visibilité opérationnelle. Le système gère gracieusement les pannes grâce à une logique de nouvelle tentative, des files d'attente de lettres mortes et une redondance, garantissant les sémantiques de livraison au moins une fois.