Étude de cas d'un service de notification : canaux, préférences, tentatives de livraison et nouvelles tentatives

Objectif

Livrer des messages provenant de nombreux producteurs aux utilisateurs sur plusieurs canaux selon leurs préférences, de sorte qu'aucun producteur ne s'adresse directement à un fournisseur, et qu'une nouvelle tentative n'envoie jamais deux fois.

Prérequis

Une liste des canaux (e-mail, push, SMS, in-app) et de leurs fournisseurs, un catalogue des types de notification avec un canal par défaut et une urgence par type, et une politique sur ce qu'un utilisateur peut désactiver.

Étapes

1. Contraintes : les producteurs ne doivent pas être bloqués par la livraison ; les fournisseurs échouent indépendamment les uns des autres ; pour la plupart des types, un doublon est pire qu'un délai ; les campagnes en masse ne doivent pas retarder les messages transactionnels.
2. Composants : une API d'ingestion qui accepte (idempotency_key, recipient, type, payload) et écrit une ligne avant de répondre ; un routeur qui déploie une notification en livraisons par canal après vérification des préférences et des plages horaires calmes ; une file d'attente par canal ; des workers de canal qui rendent les templates et appellent les fournisseurs ; un récepteur de callbacks pour les rebonds, les plaintes et les jetons invalides.
3. Modèle de données : notification(id, idempotency_key unique, recipient, type, payload, created_at) ; delivery(id, notification_id, channel, address, status, attempts, next_attempt_at, provider_message_id, last_error) ; preference(recipient, type, channel, enabled) ; device_token(recipient, token, platform, invalidated_at). La clé unique rend inoffensives les nouvelles tentatives du producteur.
4. Nouvelles tentatives : chaque canal a son propre calendrier de backoff avec gigue et un maximum ; classer les erreurs de fournisseur comme pouvant être retentées (délais dépassés, 5xx, limites de débit) ou terminales (adresse invalide, désabonnement). Pour le Web Push, la RFC 8030 exige un en-tête TTL sur chaque requête de livraison, en secondes, et précise qu'une fois ce délai écoulé, le service de push ne doit plus tenter la livraison ; une notification urgente devrait porter un TTL court plutôt que d'être retentée pendant des heures après avoir cessé d'être utile.
5. Modes de défaillance : un worker qui plante après acceptation par le fournisseur mais avant la mise à jour de la ligne (un doublon ; conserver l'identifiant de message du fournisseur, préférer des fournisseurs dotés d'API d'envoi idempotentes) ; une panne de fournisseur qui fait grossir l'arriéré (abandonner par âge les types sensibles au temps plutôt que de les livrer en retard) ; un template qui échoue pour une locale (faire échouer cette livraison, pas le worker) ; des campagnes qui affament le trafic transactionnel (files d'attente ou priorités séparées) ; des jetons invalidés silencieusement (traiter les callbacks et élaguer).
6. Mesurer : le temps entre l'ingestion et l'acceptation par le fournisseur pour chaque canal, le nombre de tentatives par livraison, le taux d'échec terminal par classe d'erreur, l'âge de la file d'attente, le taux de désabonnement par type.
7. Pas en priorité : le basculement multi-fournisseur, les digests et le regroupement, les plafonds de débit par utilisateur, un éditeur de templates, l'analytique d'engagement, les tests de formulation.

Résultat attendu

Les producteurs appellent une seule API ; chaque livraison est soit accusée réception par un fournisseur, soit terminalement échouée avec un motif, soit encore planifiée ; rejouer une requête d'un producteur ne produit pas de second message.

Limites et base de vérification

Conception proposée, sans mesures. La suppression des doublons à la frontière du fournisseur dépend du fournisseur ; sans API d'envoi idempotente, la conception accepte de rares doublons après un plantage.