Concevoir un système de notifications e‑commerce en temps réel

Aperçu Je propose une plateforme de notification évolutive horizontalement et axée sur le streaming, construite à partir de microservices découplés et de services cloud gérés. Idées clés : utiliser un journal d'événements durable pour l'ingestion et la relecture (Kafka/Kinesis/Pub/Sub), des processeurs de flux pour enrichir et personnaliser les événements, un pipeline de livraison qui persiste l'état de livraison et effectue des nouvelles tentatives pour des garanties d'au moins une fois, et des connecteurs spécifiques à l'appareil pour le push (APNs/FCM) et le web en temps réel (WebSocket). La conception répond à des pics de 100k notifications/min (≈1,7k/sec), vise une livraison en moins de 5 secondes pour 99 % des messages, et prend en charge la personnalisation et la livraison fiable. Architecture de haut niveau (composants et interactions) 1) Producteurs d'événements - Sources : Service de commande (mises à jour de commande), Service de tarification (changements de prix), Marketing/CRM (ventes flash). Chaque service émet des événements légers vers la couche d'ingestion chaque fois qu'un changement pertinent se produit. Les événements incluent event_id, event_type, payload, timestamp et métadonnées (user_ids ou product_ids). 2) Ingestion / Journal d'événements durable - Journal partitionné géré : Apache Kafka (auto-géré ou Confluent Cloud) ou équivalents cloud (AWS Kinesis Data Streams, GCP Pub/Sub). Les producteurs publient des événements dans des rubriques organisées par type d'événement et clé de partition (user_id ou product_id) pour préserver l'ordre si nécessaire (par exemple, mises à jour de commande par commande). - Pourquoi un journal durable : offre la rejouabilité, la rétention pour les nouvelles tentatives et l'atténuation du contre-pression. 3) Traitement de flux / Couche d'enrichissement - Processeurs de flux sans état/avec état (Apache Flink, Kafka Streams ou Dataflow géré) s'abonnent aux rubriques d'événements pour : valider les événements, enrichir avec le profil et les préférences de l'utilisateur, joindre avec les données de produit/segment, et décider de l'éligibilité et de la priorité de la notification (par exemple, mise à jour de commande critique vs marketing). - Sortie : Tâches de notification normalisées (task_id, user_id(s), payload, type, priorité, ttl, dedup_key) publiées dans une rubrique de Tâches de notification. 4) Personnalisation et segmentation - Les règles de personnalisation résident dans un service combinant : un magasin de fonctionnalités / une base de données de profil (DynamoDB/Cassandra/Postgres + cache Redis pour les lectures fréquentes), et un moteur de règles ou un modèle ML. Les processeurs de flux appellent ce service ou utilisent des recherches en cache local pour déterminer les destinataires ciblés et les variantes de contenu. - Pour les événements de segmentation larges (vente flash à un segment), utilisez des segments précalculés stockés dans un magasin rapide (Redis, Druid ou recherche BigQuery/ElastiCache) pour développer des listes d'utilisateurs ou appliquer une logique de filtrage dans les travaux de streaming. 5) Orchestration de livraison / Fan-out - Un service d'orchestration de livraison s'abonne à la rubrique des tâches de notification, évalue les enregistrements des appareils, les règles de limitation et la stratégie de fan-out. Pour les notifications à utilisateur unique (mise à jour de commande), il crée un travail de livraison par appareil ; pour la diffusion basée sur des segments, il se déploie en de nombreux travaux de livraison via une file d'attente partitionnée. - Les travaux de livraison sont placés dans des files d'attente de livraison persistantes par fragment (rubriques Kafka, Redis Streams ou SQS avec FIFO pour l'ordre si nécessaire). Les travaux incluent des compteurs de tentatives et des clés d'idempotence/de déduplication. 6) Travailleurs de livraison / Connecteurs - Flotte de travailleurs sans état auto-évolutive en fonction du décalage de la file d'attente. Chaque travailleur récupère les travaux, tente la livraison via le connecteur approprié pour le canal de l'appareil : - Push mobile : FCM (Android) et APNs (iOS) à l'aide de jetons d'appareil stockés dans le registre des appareils. - Web/Navigateur : Web Push (VAPID) ou connexions WebSocket persistantes (gérées via un service de connexion comme AWS API Gateway WebSocket ou des clusters de sockets auto-gérés derrière ELB). - Canaux de secours : Email (SES/SendGrid) ou SMS (Twilio) pour les notifications critiques non livrées. - Les travailleurs persistent les tentatives de livraison (succès/échec) dans un magasin d'état de livraison et émettent des événements d'achèvement ou de nouvelle tentative dans le journal pour la surveillance et les nouvelles tentatives ultérieures. 7) Registre des appareils et préférences utilisateur - Magasin durable de user_id -> appareils (jeton, plateforme, dernière connexion, préférences, indicateurs d'opt-in). Utilisez DynamoDB/Cassandra pour un débit d'écriture élevé ; mettez en cache les appareils actifs dans Redis pour des recherches à faible latence. 8) État de livraison et rejouabilité - Toutes les tâches de notification et les tentatives de livraison sont enregistrées dans des magasins durables (Kafka + archivage vers S3) et une base de données d'état de livraison. Cela permet une livraison au moins une fois, l'audit et la réconciliation. Les livraisons non acquittées/échouées sont retentées par un orchestrateur de nouvelles tentatives avec une exponentielle décroissante. 9) Surveillance, Observabilité et application des SLA - Métriques : taux d'ingestion, latence de traitement, décalage de la file d'attente, taux de réussite de la livraison. Traces pour la latence par chemin (OpenTelemetry), et alertes pour les violations de SLA. Tableaux de bord pour surveiller la latence p99 et les taux d'échec par canal. Choix de conception clés et justifications - Journal d'événements durable (Kafka/Kinesis/PubSub) : fournit un débit élevé et une rejouabilité essentiels pour la sémantique au moins une fois et le débogage. Le partitionnement par user_id/product_id préserve l'ordre par entité (critique pour les mises à jour de commande). Le streaming cloud géré réduit la surcharge opérationnelle. - Traitement de flux (Flink/Kafka Streams/Dataflow) : permet un enrichissement et une segmentation en moins d'une seconde près de l'ingestion. Le traitement de flux avec état prend en charge les jointures fenêtrées (par exemple, faire correspondre les événements de baisse de prix aux listes de souhaits) à faible latence. - Registre des appareils dans NoSQL + cache : DynamoDB/Cassandra évolue horizontalement pour des dizaines de millions d'utilisateurs ; Redis gère les recherches de chemin à chaud pour des décisions à faible latence. - Files d'attente de livraison et travailleurs auto-évolutifs : découple le fan-out intensif du traitement en amont, permettant une mise à l'échelle gracieuse pendant les ventes flash tout en contrôlant les limites de débit des fournisseurs de push en aval. - Connecteurs push (APNs/FCM) + WebSockets : les services push minimisent le polling client et atteignent une faible latence. Les WebSockets sont utilisés pour la livraison en temps réel dans l'application/le web ; si le WebSocket n'est pas disponible, le système se rabat sur le push ou le pull. - Au moins une fois, idempotence et déduplication : stocker une clé de déduplication au niveau de la tâche et rendre la livraison idempotente côté client ou utiliser des accusés de réception SDK si possible. Côté serveur, dédupliquer par task_id/dedup_key avant de créer des notifications visibles par l'utilisateur. Répondre aux exigences - Débit élevé : le journal partitionné et les travailleurs auto-évolutifs prennent en charge la mise à l'échelle horizontale ; Kafka/Kinesis peut gérer des millions d'événements/sec avec plusieurs partitions. 100k/min est modeste pour de tels systèmes ; l'architecture peut évoluer vers des volumes beaucoup plus importants en ajoutant des partitions et des travailleurs. - Faible latence : l'enrichissement en flux et les connecteurs push/WebSocket directs sont des chemins à faible latence. Cibler <5s p99 : maintenir le pipeline de traitement en moins de 1 à 2 secondes (travaux de streaming), maintenir un faible décalage de la file d'attente de livraison grâce à des travailleurs auto-évolutifs, et utiliser des caches d'appareils pour éviter les recherches en base de données sur le chemin critique. - Fiabilité : le journal d'événements durable + les états de livraison persistants + l'orchestrateur de nouvelles tentatives garantissent une livraison au moins une fois. Pour les notifications critiques (mises à jour de commande), activer des garanties plus fortes : accusé de réception synchrone des services en aval et stockage d'un reçu de livraison confirmé (par exemple, accusé de réception de l'appareil ou confirmation du canal de secours). Utiliser une exponentielle décroissante et une escalade vers des canaux alternatifs. - Évolutivité : toutes les pièces avec état utilisent des magasins évolutifs horizontalement (Kafka, DynamoDB/Cassandra, clusters Redis). Les travailleurs et les streamers sont des conteneurs sans état qui s'auto-évoluent. Utiliser le partitionnement et le sharding pour la croissance. - Personnalisation : les jointures en temps réel dans les processeurs de flux plus le magasin de profils mis en cache permettent une personnalisation par utilisateur. Les segments précalculés accélèrent les fan-outs importants (ventes flash) en évitant l'évaluation par utilisateur à la volée. Compromis (Cohérence, Disponibilité, Coût) - Cohérence vs Disponibilité : nous privilégions la disponibilité et la cohérence éventuelle pour les notifications marketing (acceptable si une promotion arrive légèrement dans le désordre). Pour les événements critiques de commande, nous utilisons un ordre et une persistance plus forts (partitionnement et persistance synchrone) pour garantir un ordre correct et une livraison fiable. Cette approche hybride équilibre l'expérience utilisateur et la résilience du système. - Au moins une fois vs Exactement une fois : obtenir exactement une fois sur l'ensemble du pipeline ajoute de la complexité et du coût (Kafka transactionnel, commit en deux phases, ou idempotence de bout en bout). Nous choisissons au moins une fois avec des gestionnaires idempotents et des clés de déduplication pour éviter les notifications dupliquées visibles tout en gardant le système plus simple et plus évolutif. - Services gérés vs auto-hébergés : le streaming géré (Kinesis/PubSub) et l'infrastructure de push réduisent le fardeau opérationnel et augmentent la disponibilité, mais coûtent plus cher. Pour la rapidité de mise sur le marché et la fiabilité à grande échelle, les services gérés sont recommandés. Si le coût devient dominant, envisagez Kafka auto-hébergé avec une automatisation solide. Considérations opérationnelles - Limitation de débit / étranglement : quotas par utilisateur et par fournisseur pour éviter la surcharge et les rejets de limites de débit des fournisseurs. - Remplissage et relecture : utiliser le journal durable pour rejouer les notifications manquées (par exemple, après une panne) et pour reconstruire l'état de livraison. - Tests : tests de chaos pour les pannes de partitions et de fournisseurs, tests de charge pour valider la latence p99 sous charge maximale. - Sécurité et confidentialité : crypter les jetons au repos, faire pivoter les identifiants push, respecter les désabonnements et les contrôles PII. SLA et KPI à surveiller - Débit (événements/min), latence de traitement de flux (p50/p90/p99), latence de livraison de bout en bout (p50/p90/p99), taux de réussite de livraison par canal, taux de nouvelles tentatives, décalage de file d'attente et décalage de groupe de consommateurs. Résumé Cette conception utilise un journal d'événements durable et partitionné plus un traitement de flux pour l'enrichissement/la personnalisation, un pipeline de livraison persistant avec des travailleurs auto-évolutifs pour le fan-out, et des connecteurs spécifiques au canal (APNs/FCM/WebSocket) pour une livraison rapide. Elle privilégie la disponibilité et la rejouabilité pour répondre à la livraison au moins une fois, utilise la mise en cache et le partitionnement pour atteindre une faible latence et un débit élevé, et s'appuie sur des composants cloud gérés pour réduire le fardeau opérationnel tout en permettant une mise à l'échelle horizontale pour soutenir la croissance future.

Conception d'un système de notification e-commerce en temps réel Aperçu Le système proposé est une architecture événementielle basée sur des microservices qui ingère des événements provenant de plusieurs services en amont, les traite et les achemine via un courtier de messages, et diffuse des notifications à 50 millions d'utilisateurs sur les canaux mobiles et web avec des garanties de livraison au moins une fois, une latence inférieure à 5 secondes au 99e centile, et la capacité de supporter 100 000 notifications par minute lors d'événements de pointe. La conception suppose un déploiement cloud-native sur AWS, bien que les principes se traduisent directement par les équivalents GCP ou Azure. Architecture de haut niveau L'architecture se compose de six couches logiques : Producteurs d'événements, Ingestion d'événements, Traitement et Routage, Préférences et Segmentation utilisateur, Diffusion, et Observabilité. 1. Producteurs d'événements Plusieurs services en amont génèrent des événements qui déclenchent des notifications. Il s'agit notamment du Service de commande (émettant des événements commande-passée, expédiée, en-cours-de-livraison, livrée), du Service de tarification (émettant des événements de baisse de prix lorsqu'un article surveillé voit son prix tomber sous un seuil), et du Service de campagne (émettant des événements de début de vente flash créés par l'équipe marketing). Chaque producteur publie une enveloppe d'événement structurée contenant un type d'événement, un horodatage, une charge utile et une clé d'idempotence vers une couche d'ingestion centrale. Les producteurs utilisent un appel de publication asynchrone, « fire-and-forget », afin que leur propre latence ne soit pas affectée. 2. Couche d'ingestion d'événements — Apache Kafka Tous les événements transitent par Apache Kafka (Amazon MSK sur AWS). Kafka est choisi pour plusieurs raisons. Premièrement, il fournit des journaux durables et immuables avec une réplication configurable (facteur de réplication de 3, min.insync.replicas de 2), ce qui signifie qu'une écriture acquittée survit à la perte de n'importe quel broker unique, soutenant directement l'exigence de fiabilité. Deuxièmement, le modèle de sujet partitionné de Kafka permet une mise à l'échelle horizontale : nous partitionnons le sujet order-events par ID utilisateur afin que tous les événements d'un utilisateur donné soient traités dans l'ordre, tandis que le sujet global peut être réparti sur des dizaines de partitions pour absorber le débit de pointe. À 100 000 notifications par minute, le taux moyen est d'environ 1 667 événements par seconde, bien dans la capacité d'un cluster Kafka modeste, mais le partitionnement nous permet de monter en charge à 10 fois plus sans changement architectural. Troisièmement, Kafka découple les producteurs des consommateurs, de sorte qu'un ralentissement temporaire de la couche de diffusion n'entraîne pas de rétro-pression sur le service de commande. Conception des sujets : sujets séparés pour order-events, price-events et campaign-events. Cela permet des groupes de consommateurs indépendants avec des politiques de mise à l'échelle et de nouvelle tentative différentes. Compromis étudié : Nous avons évalué Amazon SQS plus SNS comme alternative gérée plus simple. SQS satisferait la livraison au moins une fois et est plus léger opérationnellement, mais il manque les garanties d'ordre de Kafka par partition et sa capacité de relecture, ce qui est précieux pour le retraitement après un bug. Le coût opérationnel supplémentaire de Kafka est justifié par les avantages d'ordre et de relecture à notre échelle. 3. Couche de traitement et de routage — Service de notification Un microservice mis à l'échelle horizontalement, le Service de notification, consomme à partir des sujets Kafka. Il effectue plusieurs tâches. Premièrement, il résout le public cible. Pour les événements de commande, la cible est un utilisateur unique (extrait de la charge utile). Pour les événements de baisse de prix, il interroge le Service de liste de souhaits ou une vue matérialisée précalculée pour trouver tous les utilisateurs surveillant cet article. Pour les événements de vente flash, il interroge le Service de segmentation pour résoudre un segment d'utilisateurs. Deuxièmement, il enrichit la notification en récupérant le nom d'affichage de l'utilisateur, l'URL de l'image du produit et le modèle de message localisé à partir d'un Service de modèles sauvegardé par un cache Redis sur un magasin PostgreSQL. Troisièmement, il applique les préférences de l'utilisateur. Chaque utilisateur a un document de préférences (stocké dans DynamoDB pour un accès clé-valeur à faible latence) spécifiant les canaux opt-in (push, email, SMS, in-app), les heures de silence et les centres d'intérêt. Le service filtre et respecte ces préférences, ce qui soutient directement l'exigence de personnalisation. Quatrièmement, il diffuse les tâches de livraison. Pour chaque paire utilisateur-canal résolue, le service produit un message de livraison sur un sujet Kafka par canal (push-delivery, email-delivery, sms-delivery, in-app-delivery). Cette étape de diffusion est critique : elle convertit un événement logique en potentiellement des millions de tâches de livraison individuelles (pour une vente flash ciblant tous les utilisateurs), et Kafka absorbe cette rafale. Mise à l'échelle : Le Service de notification s'exécute en tant que déploiement Kubernetes (Amazon EKS) avec un autoscaler horizontal de pods indexé sur le décalage du consommateur Kafka. Pendant une vente flash, le décalage du consommateur augmente, et des pods supplémentaires démarrent en quelques secondes. Idempotence : Chaque message de livraison porte la clé d'idempotence de l'événement d'origine combinée à l'ID utilisateur. Les workers de livraison en aval utilisent cette clé composite pour dédupliquer, garantissant que même si Kafka fournit des sémantiques au moins une fois, les utilisateurs ne reçoivent pas de notifications dupliquées. 4. Préférences et segmentation utilisateur Les préférences utilisateur sont stockées dans Amazon DynamoDB, partitionnées par ID utilisateur. DynamoDB est choisi pour sa latence de lecture à un chiffre en millisecondes et sa mise à l'échelle horizontale transparente, ce qui est important car chaque notification individuelle nécessite une recherche de préférences. Un cache DAX (DynamoDB Accelerator) se trouve devant pour les clés chaudes. Pour la segmentation (ciblage des utilisateurs intéressés par une catégorie, ou utilisateurs d'une région géographique), nous maintenons des listes de membres de segments précalculées. Un travail par lots nocturne (Apache Spark sur EMR) et un processeur de flux en temps réel (Kafka Streams ou Flink) maintiennent ces listes à jour dans une table DynamoDB distincte indexée par ID de segment, la valeur étant une liste d'ID utilisateur stockée dans S3 pour les très grands segments. Lorsque le Service de campagne crée une vente flash ciblant le segment électronique, le Service de notification lit l'appartenance au segment et l'itère, produisant des tâches de livraison par lots. Compromis : Le précalcul des segments échange le stockage et la fraîcheur (un utilisateur qui a modifié ses préférences il y a une heure pourrait toujours être dans l'ancien segment) contre la vitesse de requête. L'évaluation de segment en temps réel au moment de la livraison serait plus précise mais nécessiterait de scanner des millions d'enregistrements utilisateur sous pression temporelle, violant l'exigence de latence. L'approche hybride (lots nocturnes plus mises à jour de flux en temps réel) maintient les segments frais en quelques minutes. 5. Couche de diffusion Des groupes de consommateurs séparés gèrent chaque canal. Notifications Push (Mobile) : Les workers consomment du sujet push-delivery et appellent Firebase Cloud Messaging (FCM) pour Android et Apple Push Notification Service (APNS) pour iOS. Nous utilisons FCM comme passerelle unifiée pour les deux plateformes lorsque cela est possible. Les workers regroupent les requêtes vers l'API HTTP v1 de FCM (jusqu'à 500 messages par appel de lot) pour maximiser le débit. Les livraisons échouées (jetons invalides, limites de débit) sont retentées avec un backoff exponentiel. Les jetons définitivement échoués (appareils non enregistrés) déclenchent un événement asynchrone pour purger le jeton du registre des appareils utilisateur. Web Push : Les workers envoient des messages du protocole Web Push en utilisant la norme VAPID. L'abonnement push de l'utilisateur (URL de point de terminaison et clés) est stocké dans le registre des appareils utilisateur (DynamoDB). Ce canal réutilise le même sujet push-delivery avec un champ de sous-type de canal. Notifications In-App : Pour les utilisateurs actuellement en ligne, nous maintenons des connexions WebSocket persistantes via une API WebSocket API Gateway (AWS API Gateway WebSocket ou un service auto-géré utilisant Socket.IO sur EKS). Un registre de connexion (Redis Cluster) mappe les ID utilisateur aux ID de connexion WebSocket. Le worker de livraison in-app recherche la connexion, et si l'utilisateur est connecté, envoie la notification en temps réel. S'il n'est pas connecté, la notification est écrite dans une boîte de réception In-App (table DynamoDB partitionnée par ID utilisateur, triée par horodatage) et livrée lorsque l'utilisateur ouvre l'application. Cette double écriture garantit qu'aucune notification n'est perdue même si l'utilisateur est hors ligne. Email et SMS : Canaux de priorité inférieure. Les workers consomment des sujets email-delivery et sms-delivery et appellent respectivement Amazon SES et Amazon SNS (SMS). Ces canaux ont une latence acceptable plus élevée (30 secondes à quelques minutes), ils peuvent donc être mis à l'échelle de manière plus conservatrice. Garanties de livraison : La livraison au moins une fois est obtenue de bout en bout. Les consommateurs Kafka valident les offsets uniquement après que l'API de livraison en aval a accusé réception (ou que le message est persisté dans la boîte de réception in-app). Si un worker plante avant la validation, le message est redélivré. La clé d'idempotence à chaque étape empêche les doublons visibles par l'utilisateur. 6. Suivi de l'état des notifications Un service d'état léger enregistre le cycle de vie de chaque notification : créée, envoyée, livrée, lue. Les accusés de réception de livraison de FCM/APNS et les accusés de lecture de l'application cliente sont ingérés via un sujet Kafka et écrits dans un magasin de séries temporelles (Amazon Timestream ou ClickHouse) pour l'analyse, et dans DynamoDB pour les requêtes d'état par utilisateur (afin que l'application puisse afficher des indicateurs lus/non lus). Ces données alimentent également la logique de nouvelle tentative : si une notification push n'est pas accusée de réception dans les 30 secondes, le système peut se rabattre sur l'e-mail. 7. Observabilité Prometheus et Grafana surveillent le décalage des consommateurs Kafka, les centiles de latence de livraison, les taux d'erreur par canal et le débit. Des alertes se déclenchent si la latence de livraison p99 dépasse 4 secondes (donnant une marge de 1 seconde avant le SLA de 5 secondes). Le traçage distribué (OpenTelemetry avec Jaeger) suit un événement du producteur à la livraison, permettant un débogage rapide. Les journaux structurés sont expédiés vers Amazon OpenSearch pour la recherche et l'audit. Répondre aux exigences Débit élevé : Les sujets partitionnés de Kafka et les groupes de consommateurs mis à l'échelle horizontalement gèrent confortablement 100 000 notifications par minute. La diffusion pour les campagnes importantes est absorbée par la mise en mémoire tampon de Kafka, et les workers de livraison s'adaptent automatiquement en fonction du décalage. Faible latence : Le chemin critique pour une notification à utilisateur unique (par exemple, commande expédiée) est le suivant : le producteur publie sur Kafka (moins de 50 ms), le Service de notification consomme et enrichit (moins de 100 ms, y compris les recherches DynamoDB et Redis), le worker de livraison envoie à FCM/APNS (moins de 500 ms typique). Total bien inférieur à 5 secondes. Pour les campagnes à grande diffusion, le système parallélise sur de nombreux workers de livraison ; le partitionnement Kafka garantit qu'aucun worker unique n'est un goulot d'étranglement. Fiabilité : La réplication Kafka, la gestion des offsets des consommateurs et la livraison idempotente garantissent des sémantiques au moins une fois. Une file d'attente de lettres mortes (DLQ) capture les messages qui échouent après un nombre configurable de nouvelles tentatives, et une équipe d'exploitation est alertée pour enquêter. Les notifications de commande critiques sont marquées avec un champ de priorité et acheminées vers une partition dédiée de haute priorité avec son propre groupe de consommateurs, garantissant qu'elles ne sont jamais affamées par un déluge de notifications promotionnelles. Scalabilité : Chaque composant s'adapte horizontalement. Les partitions Kafka peuvent être augmentées. Les pods Kubernetes s'adaptent automatiquement. DynamoDB s'adapte à la demande. Il n'y a pas de points de défaillance uniques ni de goulots d'étranglement à thread unique. Personnalisation : Les préférences utilisateur dans DynamoDB contrôlent la sélection du canal et les heures de silence. Les segments précalculés permettent des campagnes ciblées. Le Service de modèles prend en charge les modèles de messages par locale, par catégorie, et les variantes de tests A/B peuvent être sélectionnées au moment de l'enrichissement. Compromis clés et justifications Cohérence vs Disponibilité : Le système privilégie la disponibilité (AP dans les termes CAP). Si le magasin de préférences est momentanément inaccessible, le Service de notification utilise une préférence mise en cache ou par défaut plutôt que de bloquer. Cela signifie qu'un utilisateur peut occasionnellement recevoir une notification sur un canal qu'il vient de désactiver, mais aucune notification n'est perdue ou retardée. Pour un système de notification e-commerce, la disponibilité et la faible latence sont plus précieuses qu'une cohérence stricte des préférences. Au moins une fois vs Exactement une fois : Une véritable livraison exactement une fois via des systèmes externes (FCM, APNS) est impraticable. Au lieu de cela, nous garantissons au moins une fois et utilisons des clés d'idempotence pour supprimer les doublons au niveau de l'application. C'est plus simple, moins cher et suffisant. Services gérés vs Auto-hébergés : Nous utilisons Kafka géré (MSK), Kubernetes géré (EKS) et des bases de données gérées (DynamoDB) pour réduire la charge opérationnelle. Le compromis est un coût par unité plus élevé par rapport à l'auto-hébergement, mais le temps d'ingénierie économisé et la fiabilité des services gérés le justifient à notre échelle. Push vs Pull pour In-App : Les WebSockets (push) offrent la latence la plus faible pour les utilisateurs en ligne mais nécessitent de maintenir des connexions persistantes et un registre de connexion. Le polling serait plus simple mais ajouterait des secondes de latence et générerait une charge inutile. L'approche hybride (WebSocket en ligne, boîte de réception hors ligne) équilibre latence et utilisation des ressources. Considérations de coût : Les principaux facteurs de coût sont le débit Kafka (tarification MSK), la capacité de lecture DynamoDB pour les recherches de préférences, et les appels API FCM/APNS (gratuits pour FCM, mais l'infrastructure pour les appeler à grande échelle ne l'est pas). Pour contrôler les coûts, nous regroupons les appels FCM, utilisons la tarification à la demande de DynamoDB (qui est rentable pour les charges de travail intermittentes) et utilisons des instances spot pour les workers de livraison non critiques (email, SMS). Conclusion Cette architecture fournit un système de notification robuste, évolutif et à faible latence, adapté à une plateforme e-commerce de 50 millions d'utilisateurs. En tirant parti de Kafka comme système nerveux central, de DynamoDB pour un accès rapide aux données utilisateur, et de workers de livraison spécifiques au canal qui s'adaptent automatiquement indépendamment, le système répond à toutes les exigences énoncées tout en restant gérable opérationnellement et rentable. La conception est extensible : l'ajout d'un nouveau canal de notification (par exemple, WhatsApp) ne nécessite qu'un nouveau worker de livraison consommant à partir d'un nouveau sujet Kafka, sans modification des producteurs d'événements en amont ni de la logique de traitement principale.