Concevoir un système de notification en temps réel pour une application de covoiturage

Architecture de haut niveau (composants et interactions) 1) Producteurs d'événements (services sources) - Service de trajet : émet des événements de cycle de vie de trajet (chauffeur_assigné, trajet_terminé). - Service de dispatch/appariement : émet des événements chauffeur_assigné et toute réassignation. - Service ETA/Localisation : calcule en continu l'ETA à partir des flux GPS du chauffeur ; émet chauffeur_en_approchant lorsqu'un seuil d'ETA (par exemple, <= 2 minutes) est franchi avec hystérésis. - Service de promotions : crée des événements de campagne avec des règles de ciblage géographique et des définitions d'audience. 2) Ingestion de notifications + Bus d'événements - Tous les services publient des événements de domaine vers un bus d'événements durable. - Les événements sont standardisés (user_id, ride_id, event_type, timestamp, payload, idempotency_key, priority, locale). 3) Orchestrateur de notifications (règles + routage) - Consomme les événements du bus. - Applique les règles métier (qui notifier : passager, chauffeur ; heures de silence ; désabonnements utilisateur ; limites de débit ; ne pas déranger ; canaux de secours). - Enrichit les notifications (récupère le nom/véhicule du chauffeur, le lien du reçu, le texte de l'ETA) via des lectures mises en cache. - Produit des « jobs de notification » vers des files d'attente spécifiques au canal avec priorité (transactionnel > promotionnel). 4) Service Utilisateur/Appareil et Préférences - Stocke les jetons d'appareil (APNs/FCM), la plateforme, la version de l'application, la dernière connexion, la langue et les préférences de notification. - Expose une recherche à faible latence (cache d'abord). 5) Workers de livraison (adaptateurs de canal) - Passerelle Push : envoie vers Apple APNs et Google FCM. - Passerelle SMS (solution de repli optionnelle pour les messages critiques) : Twilio ou agrégateur direct. - Passerelle In-app/WebSocket (optionnelle) : pour les utilisateurs actuellement actifs dans l'application. 6) Suivi de livraison + Nouvelle tentative + DLQ - Les tentatives de livraison sont enregistrées (envoyé, accepté par le fournisseur, échoué avec raison). - Nouvelles tentatives automatiques avec backoff exponentiel pour les échecs transitoires. - File d'attente de lettres mortes pour les messages empoisonnés ; outils d'alerte et de rejeu. 7) Pipeline de ciblage promotionnel - Constructeur d'audience géographique : convertit les zones géographiques (cellules geohash/H3) + critères d'éligibilité en ensembles d'utilisateurs cibles. - Utilise des signaux de localisation quasi en temps réel (dernière localisation connue) et/ou la région domicile/travail. - Produit des lots de jobs de notification dans des files d'attente de priorité inférieure avec limitation. 8) Observabilité et Opérations - Métriques : latence de bout en bout p50/p95/p99, décalage de file d'attente, taux d'erreur des fournisseurs, taux d'invalidation de jetons. - Traçage : corréler event_id → job_id → provider request_id. - Console d'administration : gestion des campagnes, rejeu, listes de suppression. Choix technologiques clés et justification 1) Mise en file d'attente des messages / streaming d'événements - Apache Kafka (ou équivalents gérés comme AWS MSK / Confluent Cloud) comme bus d'événements central. Justification : débit élevé pendant les heures de pointe, partitionnement pour la mise à l'échelle horizontale, journal durable pour le rejeu, groupes de consommateurs pour la mise à l'échelle indépendante, bien adapté au traitement au moins une fois. - Sujets séparés pour : - événements de trajet (transactionnels) - événements eta - événements promo - notification-jobs-high (prioritaire) - notification-jobs-low (promo) - résultats de livraison 2) Magasins de données - Jetons d'appareil et préférences : DynamoDB (ou Cassandra) indexé par user_id. Justification : lectures prévisibles à faible latence à grande échelle, haute disponibilité, mise à l'échelle horizontale facile. - Suivi de livraison / analytique : - Chemin chaud : DynamoDB/Cassandra pour l'état récent (dernier statut par notification_id). - Analytique à long terme : data lake (S3/GCS) + entrepôt de données (Snowflake/BigQuery) alimenté par Kafka Connect. - Métadonnées de campagne/audience : Postgres (ou Aurora) pour la gestion relationnelle (campagnes, calendriers, créations). - Mise en cache : Redis (clusterisé) pour les recherches de jetons d'appareil, le cache des préférences utilisateur et les fragments de modèles. 3) Services de notification push - APNs pour iOS et FCM pour Android. Justification : infrastructure de push officielle, fiable et évolutive ; prend en charge la priorité et les clés de réduction. - Fournisseur SMS optionnel pour le secours afin d'assurer la fiabilité des notifications transactionnelles critiques. 4) Ciblage géographique - Indexation H3 ou Geohash pour les régions géographiques. Justification : mappage efficace de lat/lon vers des cellules discrètes ; prend en charge la requête « utilisateurs dans ces cellules ». - Traitement de flux : Kafka Streams / Flink pour maintenir l'appartenance « utilisateurs dans cellule » basée sur les mises à jour de localisation. Faible latence (<2s) et haute fiabilité (au moins une fois) 1) Stratégie de faible latence - Prioriser les notifications transactionnelles : - Utiliser des sujets/files d'attente dédiés à haute priorité et des pools de workers. - Appliquer des SLA stricts par message : fenêtres de traitement courtes (ou aucune) pour les événements urgents. - Enrichissement basé sur le cache : - L'orchestrateur lit les jetons d'appareil/préférences depuis Redis ; se rabat sur DynamoDB en cas de cache manquant. - Garder la charge utile minimale ; inclure des liens profonds pour récupérer les détails dans l'application. - Minimiser les dépendances synchrones : - Les producteurs publient les événements de manière asynchrone. - L'orchestrateur évite d'appeler plusieurs microservices en ligne ; utilise des données précalculées (par exemple, informations du chauffeur déjà dans l'événement ou obtenables depuis le cache). - Réutilisation des connexions et meilleures pratiques du fournisseur : - Maintenir des connexions HTTP/2 persistantes vers APNs ; réutiliser les connexions FCM. - Utiliser correctement les indicateurs de priorité du fournisseur. - Contrôler le bruit « en approchant » : - Le service ETA n'émet que lors du franchissement du seuil avec un délai de refroidissement (par exemple, ne pas renvoyer dans les N minutes) pour réduire la charge et maintenir la latence pour les messages critiques. 2) Livraison au moins une fois et exactitude - Au moins une fois depuis Kafka + validation du consommateur après traitement. - Idempotence : - Chaque job de notification porte une clé d'idempotence déterministe (par exemple, user_id + ride_id + event_type + version). - L'orchestrateur écrit un enregistrement « job créé » (ou clé de déduplication) avec une écriture conditionnelle pour éviter la création de jobs dupliqués lors des rejeux. - Les workers de livraison enregistrent les tentatives indexées par notification_id pour éviter les doubles envois lorsque possible. - Déduplication au niveau du fournisseur : - Utiliser les clés de réduction APNs/FCM pour certains types (par exemple, chauffeur en approche) afin que le dernier remplace le précédent. - Politique de nouvelle tentative : - Échecs transitoires : réessayer avec backoff exponentiel et jitter. - Échecs permanents (jeton invalide) : marquer le jeton comme invalide, arrêter les nouvelles tentatives. - DLQ pour les échecs répétés ; flux d'opérateurs pour le rejeu. 3) Fiabilité et disponibilité - Déploiement multi-AZ pour Kafka, Redis, DynamoDB (géré) et services sans état. - Backpressure : - Si les fournisseurs push se dégradent, les files d'attente absorbent les pics ; les workers s'adaptent mais sont limités pour éviter les limites de débit des fournisseurs. - Exactement une fois n'est pas requis ; au moins une fois avec idempotence est suffisant pour les notifications destinées aux utilisateurs. Mise à l'échelle pour gérer les charges de pointe 1) Estimation du débit (ordre de grandeur) - 500k trajets/jour ; chaque trajet peut générer 2 à 4 notifications transactionnelles (assigné, en approche, terminé/reçu) pour le passager ; plus les notifications côté chauffeur. - Les pics pendant les heures de pointe peuvent être 10 à 20 fois supérieurs à la moyenne. Conception pour plusieurs milliers de notifications/seconde en rafales soutenues. 2) Approche de mise à l'échelle horizontale - Partitionnement Kafka : - Partitionner par user_id (ou ride_id) pour conserver l'ordre par utilisateur/trajet pour les notifications liées. - Mettre à l'échelle les partitions pour correspondre au parallélisme attendu des consommateurs de pointe. - Services sans état : - L'orchestrateur et les workers de livraison sont sans état et auto-adaptatifs (HPA Kubernetes basé sur le CPU + décalage de file d'attente). - Pools séparés et isolation : - Sujets/files d'attente et déploiements de workers séparés pour le transactionnel vs promotionnel. - Quotas stricts pour que les promotions ne privent jamais la livraison transactionnelle. 3) Mise à l'échelle des messages promotionnels - Précalculer l'audience : - La campagne s'étend aux cellules H3 ; récupérer les utilisateurs éligibles via le magasin « utilisateurs dans cellule ». - Fanout par lots avec limitation ; mettre en file d'attente les jobs dans la file d'attente de priorité inférieure. - Limitation du débit : - Caps globaux et par région ; découpage temporel entre les cellules. - Respecter les caps de fréquence par utilisateur et les désabonnements. 4) Mise à l'échelle des données et du cache - Cluster Redis dimensionné pour des lectures QPS élevées ; utiliser le hachage cohérent et la réplication. - DynamoDB/Cassandra avec une capacité de lecture suffisante ; le cache le protège pendant les pics. - Gestion de l'invalidation des jetons pour réduire les envois répétés échoués. Principaux compromis 1) Au moins une fois vs exactement une fois - Compromis : au moins une fois peut entraîner des doublons ; exactement une fois ajouterait de la complexité et de la latence. - Décision : accepter au moins une fois avec des clés d'idempotence et des clés de réduction solides pour minimiser les doublons visibles par l'utilisateur. 2) Cohérence vs disponibilité - Les jetons/préférences d'appareil peuvent être légèrement obsolètes (cohérence éventuelle) si un utilisateur modifie ses paramètres. - Décision : privilégier la disponibilité et la faible latence ; utiliser des caches à courte durée de vie et le versionnement pour converger rapidement. 3) Coût vs performance - Maintenir un index d'audience géographique en temps réel et un processeur de flux coûte plus cher que le ciblage par lots. - Décision : utiliser le ciblage géographique quasi en temps réel uniquement lorsque nécessaire ; sinon, autoriser les campagnes avec une expansion par lots plus lente. Isoler les charges de travail promotionnelles sur une capacité moins coûteuse. 4) Approche d'enrichissement de la charge utile - Les messages entièrement enrichis nécessitent plus de lectures synchrones et peuvent augmenter la latence. - Décision : garder la charge utile push petite et s'appuyer sur des liens profonds ; enrichir uniquement lorsque les données sont déjà dans l'événement ou mises en cache. 5) Dépendances du fournisseur et secours - L'ajout d'un secours SMS augmente les coûts et le champ d'application de la conformité. - Décision : activer le secours SMS uniquement pour les notifications transactionnelles critiques (par exemple, chauffeur assigné/en approche) et uniquement lorsque le push échoue de manière répétée ou que l'utilisateur n'a pas de jeton valide. Résumé Cette conception utilise une colonne vertébrale de streaming d'événements durable (Kafka), un orchestrateur de notifications basé sur des règles et des workers de livraison de canaux évolutifs pour obtenir une livraison de notifications transactionnelles inférieure à 2 secondes avec une fiabilité au moins une fois. Elle s'adapte horizontalement via le partitionnement et l'auto-adaptation, isole le trafic promotionnel pour protéger les messages sensibles au temps, et gère les doublons via l'idempotence et les clés de réduction du fournisseur tout en équilibrant le coût et la complexité opérationnelle.

Système de notification de covoiturage en temps réel : Conception d'architecture de haut niveau Aperçu Le système de notification doit délivrer de manière fiable des messages sensibles dans le temps à 1 million d'utilisateurs actifs quotidiens sur 500 000 trajets quotidiens, avec une latence inférieure à 2 secondes et des garanties de livraison au moins une fois. La conception suit une architecture pilotée par les événements et basée sur des microservices, avec une séparation claire entre la production d'événements, le routage, la livraison et le suivi. --- 1. Composants architecturaux de haut niveau et interactions Le système est composé de cinq couches principales : Producteurs d'événements : Les services centraux de mise en correspondance des trajets et de gestion des trajets émettent des événements de domaine (chauffeur attribué, chauffeur arrivant, trajet terminé, promotion déclenchée) vers un courtier de messages central. Ces services sont entièrement découplés du système de notification. Courtier de messages (Bus d'événements) : Une plateforme de streaming distribuée ingère tous les événements et les diffuse aux consommateurs en aval. C'est l'épine dorsale du pipeline asynchrone. Service d'orchestration des notifications : Un microservice sans état qui consomme les événements du courtier, les enrichit avec les préférences de l'utilisateur et les jetons d'appareil (récupérés d'un magasin de profils utilisateur), détermine le canal de notification correct (push, SMS, in-app) et publie des travaux de notification formatés dans des files d'attente spécifiques au canal. Travailleurs de livraison de canal : Pools de travailleurs dédiés pour chaque canal (APNs pour iOS, FCM pour Android, Twilio pour SMS, serveur WebSocket pour in-app). Chaque travailleur consomme à partir de sa file d'attente, appelle la passerelle tierce appropriée et enregistre l'état de la livraison. Magasin de suivi et d'audit de livraison : Un journal persistant de chaque tentative de notification, son état (envoyé, livré, échoué) et les horodatages. Cela alimente les tableaux de bord et la logique de nouvelle tentative. Résumé du flux : Le service de trajet émet un événement → Courtier de messages → L'orchestrateur enrichit et achemine → File d'attente du canal → Travailleur de livraison → Passerelle Push/SMS → Appareil. L'état de la livraison est renvoyé au magasin d'audit de manière asynchrone. --- 2. Choix technologiques clés et justifications Courtier de messages : Apache Kafka. Kafka fournit un streaming d'événements durable, ordonné et à haut débit avec une rétention configurable. Son modèle de groupe de consommateurs permet à plusieurs instances d'orchestrateur de traiter les événements en parallèle. Le facteur de réplication de Kafka (défini sur 3) garantit qu'aucun événement n'est perdu si un nœud du courtier tombe en panne. Pour les pics d'heure de pointe, Kafka absorbe les rafales sans rétroaction sur les services en amont. Orchestrateur et travailleurs : Microservices Go ou Java déployés sur Kubernetes. Go offre une faible surcharge mémoire et une haute concurrence via les goroutines, idéales pour la distribution des notifications liées aux E/S. Kubernetes permet l'autoscaling horizontal des pods basé sur les métriques de décalage des consommateurs Kafka. Magasin de profils utilisateur et de jetons d'appareil : Redis (principal, pour les données chaudes) sauvegardé par PostgreSQL (source de vérité). Les jetons d'appareil et les préférences utilisateur sont mis en cache dans Redis avec un TTL. Le modèle de cache-aside garantit que l'orchestrateur récupère les jetons en moins d'1 ms en cas de succès du cache, évitant les goulots d'étranglement de la base de données à grande échelle. Passerelles de notification push : Firebase Cloud Messaging (FCM) pour Android et Apple Push Notification service (APNs) pour iOS. Les deux prennent en charge les API d'envoi par lots. Pour le secours SMS, Twilio offre une livraison mondiale fiable avec des accusés de réception de livraison. Canal In-App / Temps réel : Une passerelle WebSocket (utilisant Socket.io ou un serveur personnalisé sauvegardé par Redis Pub/Sub) maintient des connexions persistantes avec les sessions d'application actives. Pour les notifications de chauffeur arrivant et de chauffeur attribué, le canal in-app est tenté en premier car c'est le chemin le plus rapide. Magasin d'audit de livraison : Apache Cassandra ou Amazon DynamoDB. Les deux sont optimisés pour un débit d'écriture élevé et des modèles d'accès chronologiques. Chaque tentative de notification est écrite comme un enregistrement immuable indexé par (user_id, notification_id, timestamp). Ciblage géographique pour les promotions : Un index géospatial utilisant PostGIS ou Redis avec les commandes GEO stocke les dernières positions connues des utilisateurs. Un service de campagne promotionnelle interroge cet index pour construire des listes d'utilisateurs cibles, puis publie des événements de notification individuels vers Kafka, en maintenant le pipeline de livraison uniforme. --- 3. Stratégie de faible latence et de haute fiabilité Faible latence (inférieure à 2 secondes de bout en bout) : Le chemin critique pour les notifications transactionnelles (chauffeur attribué, chauffeur arrivant) est : émission d'événement → ingestion Kafka (< 10 ms) → traitement de l'orchestrateur, y compris la recherche de jeton Redis (< 50 ms) → appel API FCM/APNs (généralement 100–400 ms) → réception par l'appareil. La latence p99 totale attendue est bien inférieure à 2 secondes en charge normale. Pour minimiser le temps de traitement de l'orchestrateur, l'enrichissement des jetons se fait via un seul appel de pipeline Redis plutôt que des recherches séquentielles. L'orchestrateur est sans état et mis à l'échelle horizontalement, de sorte qu'aucune instance unique ne constitue un goulot d'étranglement. La livraison WebSocket pour les notifications in-app contourne entièrement les passerelles push, atteignant une livraison inférieure à 100 ms pour les utilisateurs ayant des sessions actives. Haute fiabilité (livraison au moins une fois) : Les décalages des consommateurs Kafka ne sont validés qu'après que l'orchestrateur a publié avec succès le travail de notification dans la file d'attente du canal. Si l'orchestrateur plante en cours de traitement, l'événement est re-consommé et re-traité. Les travailleurs de livraison de canal utilisent une clé d'idempotence (dérivée de notification_id) lors de l'appel à FCM/APNs, empêchant les notifications dupliquées même si un travailleur réessaie après un échec transitoire. Une file d'attente de lettres mortes (DLQ) capture les notifications qui échouent après un nombre configurable de nouvelles tentatives (par exemple, 3 tentatives avec une exponentielle de recul). Un système d'alerte surveille la profondeur de la DLQ et déclenche une escalade d'astreinte. Pour le secours SMS : si la livraison push n'est pas acquittée dans les 30 secondes (vérifié via les accusés de réception de livraison FCM), le système bascule automatiquement vers SMS pour les notifications critiques (chauffeur attribué, trajet terminé). --- 4. Stratégie de mise à l'échelle pour les charges de pointe Les pics d'heure de pointe sont prévisibles (trajets du matin et du soir). Le système utilise deux approches de mise à l'échelle complémentaires : Mise à l'échelle proactive (planifiée) : Le Horizontal Pod Autoscaler (HPA) de Kubernetes est pré-chauffé avant les fenêtres de pointe connues à l'aide d'une politique de mise à l'échelle basée sur cron. Le nombre de répliques de l'orchestrateur et des travailleurs est augmenté 10 minutes avant l'heure de pointe. Mise à l'échelle réactive : Le décalage des consommateurs Kafka est exposé comme une métrique personnalisée au serveur de métriques Kubernetes. Si le décalage sur le sujet de notification dépasse un seuil (par exemple, 10 000 messages non traités), le HPA ajoute automatiquement des pods d'orchestrateur. Les pools de travailleurs s'adaptent de manière similaire en fonction de la profondeur de leurs files d'attente. Partitionnement Kafka : Le sujet de notification est partitionné par user_id (ou ride_id) pour garantir un traitement ordonné par utilisateur tout en permettant un parallélisme élevé. Avec 100 partitions, jusqu'à 100 instances d'orchestrateur peuvent traiter simultanément. Les notifications promotionnelles, qui sont en masse et non critiques en termes de temps, sont traitées sur un sujet Kafka séparé de priorité inférieure avec un groupe de consommateurs dédié. Cela empêche les rafales promotionnelles de concurrencer les notifications transactionnelles pour les ressources de traitement. Mise à l'échelle de la base de données : Redis est déployé en cluster avec des répliques de lecture. PostgreSQL utilise la mise en commun des connexions (PgBouncer) et des répliques de lecture pour les recherches de profil. Cassandra s'adapte horizontalement en ajoutant des nœuds. Débit estimé : 500 000 trajets/jour avec une moyenne de 3 notifications par trajet équivaut à 1,5 million de notifications transactionnelles par jour, soit environ 17 par seconde en moyenne. Pendant un pic d'heure de pointe de 2 heures gérant 30 % des trajets quotidiens, le débit de pointe atteint environ 70 notifications par seconde. Ceci est bien dans la capacité d'un cluster Kafka et de travailleurs modeste, laissant une marge de manœuvre importante. --- 5. Compromis majeurs Livraison au moins une fois vs. livraison exactement une fois : La livraison exactement une fois dans les systèmes distribués et les passerelles tierces (FCM, APNs) est pratiquement impossible à garantir de bout en bout. La conception accepte les sémantiques au moins une fois et atténue la livraison en double à l'aide de clés d'idempotence. Le compromis est des notifications occasionnellement dupliquées (par exemple, deux messages « chauffeur attribué ») par rapport à la complexité et au coût de latence des transactions distribuées. Pour une application de covoiturage, un doublon rare est bien moins préjudiciable qu'une notification manquée. Coût vs. Performance : Maintenir une connexion WebSocket persistante pour chaque utilisateur actif coûte cher en ressources serveur. La conception utilise les WebSockets uniquement pour les utilisateurs ayant des sessions d'application actives (généralement pendant un trajet actif), en se rabattant sur les notifications push sinon. Cela réduit les coûts d'infrastructure tout en préservant une faible latence pour les moments les plus critiques. Cohérence vs. Disponibilité : Le cache de jetons Redis peut servir un jeton d'appareil obsolète si un utilisateur réinstalle l'application et que le cache n'a pas encore été invalidé. La conception accepte cette fenêtre de cohérence éventuelle (généralement de quelques secondes à quelques minutes) en échange des avantages de disponibilité et de latence de la mise en cache. Une notification push échouée en raison d'un jeton obsolète déclenche un rafraîchissement du cache et une nouvelle tentative, de sorte que l'impact est une notification légèrement retardée plutôt qu'une notification perdue. Simplicité vs. Flexibilité du routage des canaux : Un moteur de routage plus sophistiqué pourrait appliquer des modèles d'apprentissage automatique pour choisir le canal optimal par utilisateur. La conception actuelle utilise un routeur simple basé sur des règles (in-app d'abord, puis push, puis secours SMS) pour la prévisibilité, une complexité opérationnelle réduite et un débogage plus facile. Cela peut être fait évoluer progressivement. Isolation des promotions : Séparer le trafic promotionnel sur son propre sujet Kafka et son propre pool de travailleurs ajoute de la complexité opérationnelle (plus de sujets à surveiller, plus de groupes de consommateurs à gérer), mais c'est un compromis nécessaire pour protéger les SLA de notification transactionnelle contre la dégradation par des envois promotionnels en masse. --- Conclusion Cette architecture offre un système de notification robuste et évolutif en combinant le streaming d'événements durable de Kafka, l'enrichissement à faible latence sauvegardé par Redis, les travailleurs de livraison multicanaux et la mise à l'échelle basée sur Kubernetes. La conception privilégie une livraison inférieure à 2 secondes pour les notifications transactionnelles et une fiabilité au moins une fois grâce à des nouvelles tentatives idempotentes et des files d'attente de lettres mortes, tout en isolant le trafic promotionnel pour protéger l'expérience utilisateur principale. Les compromis effectués privilégient la simplicité opérationnelle et la disponibilité par rapport à la perfection théorique, ce qui convient à un produit grand public à haute vélocité.