Un événement, trois mécanismes de livraison

Un seul événement logique — « le statut de ta demande a changé » — doit atteindre l'utilisateur par des mécanismes vraiment différents : une notification in-app (une ligne affichée à la prochaine ouverture de l'application), un web push (via l'API Push du navigateur et un service worker), un mobile push (routé par le service de push d'Expo). Chacun a des modes de défaillance différents. Du côté de l'utilisateur, c'est une seule chose : « préviens-moi ».

Sépare l'événement de la livraison

notifications — l'événement logique, ce qui s'est passé et pour qui — est gardé séparé de notification_deliveries — chaque tentative de livraison sur un canal précis. Un événement se ventile en plusieurs lignes de livraison, chacune suivie indépendamment avec son propre statut et son canal. Un échec sur un canal — un abonnement web push périmé — n'affecte pas et n'est pas confondu avec les autres pour le même événement.

notification_preferences donne un contrôle par événement, par canal plutôt qu'un unique interrupteur global. Un utilisateur peut vouloir in-app plus e-mail pour les changements de statut et explicitement ne pas vouloir qu'un mobile push l'interrompe pour chaque message de chat. Cette granularité est ce qui respecte le comportement réel.

La livraison passe par le même outbox transactionnel que l'e-mail — l'événement est écrit durablement d'abord, puis le processeur le ventile sur les canaux que les préférences disent devoir recevoir, réessayant les livraisons échouées propres à un canal indépendamment plutôt que toute la notification réussisse ou échoue comme une seule unité.

Au-dessus des préférences individuelles se trouve un interrupteur au niveau opérateur — une organisation pourrait désactiver le web push pour toute sa communauté, ce qui contraint ce que les utilisateurs individuels peuvent même choisir. Deux couches : « ce canal est-il disponible ici tout court » et « est-ce que je veux ça sur ce canal », toutes deux vérifiées avant de tenter la livraison.

Les notifications sont faciles à greffer tard comme un simple appel sendEmail(), mais elles touchent l'identité, la préférence, les détails techniques de canal et la fiabilité tout à la fois. Les traiter comme leur propre domaine — leurs propres tables, modèle de préférence, suivi de livraison — paie une fois qu'il y a plus d'un canal et plus d'un type de notification, ce qui arrive plus vite dans un vrai produit qu'il n'y paraît au départ.