Concevez un système de notifications qui envoie des e-mails et alimente un fil dans l'application.

Écrivez la notification dans une table comme source de vérité, puis mettez en file un job de livraison par canal pour qu'un fournisseur d'e-mail en panne ne bloque jamais le fil dans l'application. Rendez les jobs idempotents et réessayez avec un backoff exponentiel vers une file de rebut. Servez le fil depuis cette table, en poussant les mises à jour par socket ou en interrogeant au retour du focus. Ajoutez des préférences par utilisateur et du regroupement pour que personne ne reçoive vingt e-mails par heure.

Je modéliserais une table notifications indexée par utilisateur avec un type, une charge utile, un horodatage de création et un horodatage de lecture, et je traiterais cette ligne comme la vérité. Créer une notification, c'est une seule écriture plus la mise en file des jobs de livraison, un par canal, donc si le fournisseur d'e-mail est en panne le fil dans l'application marche quand même et l'e-mail réessaie plus tard. Chaque job porte une clé d'idempotence stable faite de l'identifiant de notification et du canal, donc une nouvelle tentative ne peut pas envoyer deux fois. Les tentatives utilisent un backoff exponentiel et atterrissent dans une file de rebut après quelques essais, avec une alerte, parce qu'un échec d'e-mail silencieux est le genre de bug qu'on apprend par un client. Le fil lui-même, c'est une simple lecture paginée sur cette table, avec les compteurs de non-lus en cache, et je pousse les nouveaux éléments par server sent events ou je refais simplement la requête quand l'onglet reprend le focus. Côté produit, les préférences vivent par utilisateur et par type, les types à fort volume sont regroupés dans un résumé quotidien, et chaque e-mail porte un désabonnement en un clic qui écrit vraiment dans ces préférences.