Développer une passerelle webhook avec signature et livraison fiable

Notre plateforme connecte de plus en plus d'intégrations partenaires, et chacune d'elles souhaite recevoir des événements via HTTP chaque fois que quelque chose se produit de notre côté. En ce moment, nous envoyons ces rappels directement depuis la requête qui les a déclenchés, et cela crée trois problèmes à la fois : un abonné lent ou indisponible bloque notre propre code, les appels échoués sont perdus silencieusement et plus tard, personne ne peut me dire si un événement spécifique a été effectivement livré. Je veux arrêter d'écrire cette logique à partir de zéro pour chaque fonctionnalité et mettre en place une passerelle webhook dédiée qui prend en charge l'ensemble du cycle de vie sortant. Elle devrait recevoir des événements entrants de nos services, les enregistrer puis dispatcher chaque événement à tous les points de terminaison abonnés à ce type, découplant complètement la livraison du code qui a généré l'événement.

La fiabilité est essentielle ici, donc je suis le plus préoccupé par les échecs des abonnés. Chaque tentative de livraison doit être signée afin que le destinataire puisse vérifier qu'elle vient de nous, porter un horodatage et un identifiant de livraison unique pour se protéger contre les doublons, et en cas d'erreur, réessayer avec un backoff exponentiel et un jitter jusqu'à une limite configurable, puis passer à l'état de lettre morte. Nous avons besoin de limites de concurrence par point de terminaison afin qu'un abonné submergé ne consomme pas les ressources des autres, et de clés d'idempotence pour qu'un réessai ne cause jamais un doublon du côté du destinataire. Pour être clair sur le périmètre : il ne s'agit pas d'une file de messages générale pour des tâches internes et pas d'un proxy de passerelle API pour le trafic entrant. Il s'agit de livrer de manière fiable des webhooks sortants à des tiers, et la file d'attente n'est qu'un mécanisme interne, pas le résultat.

J'ai également besoin d'observabilité et de gestion que je peux transmettre au support et aux partenaires. Chaque tentative devrait figurer dans un journal de livraison avec la requête, le code de réponse, la latence et le nombre de réessais, pouvant être recherchée par événement, point de terminaison et statut. Il devrait y avoir un moyen de réessayer manuellement les livraisons échouées ou en état de lettre morte, de mettre un point de terminaison en pause et de le reprendre, et de faire tourner les secrets de signature sans temps d'arrêt. Veuillez traiter cela comme une infrastructure de production — avec une documentation claire et des tests, pas un prototype.

— Point de terminaison pour recevoir des événements entrants avec validation et persistance
— Modèle d'abonnement : correspondance des types d'événements aux points de terminaison des abonnés
— Charges utiles signées avec horodatage, identifiant de livraison et protection contre les doublons
— Réessais avec backoff exponentiel, jitter et état de lettre morte
— Limites de concurrence par point de terminaison et gestion de l'idempotence
— Journal de livraison avec recherche, réessai manuel et pause de point de terminaison
— Rotation des secrets, documentation et autotests