Opracuj bramkę webhook z podpisywaniem i niezawodną dostawą

Nasza platforma łączy coraz więcej integracji partnerskich, a każda z nich chce otrzymywać zdarzenia przez HTTP, gdy coś się dzieje po naszej stronie. Obecnie wysyłamy te wywołania bezpośrednio z żądania, które je wywołało, co powoduje trzy problemy jednocześnie: wolny lub niedostępny subskrybent blokuje nasz własny kod, nieudane wywołania są cicho tracone, a później nikt nie może mi powiedzieć, czy konkretne zdarzenie zostało faktycznie dostarczone. Chcę przestać pisać tę logikę od podstaw dla każdej funkcji i skonfigurować jedną dedykowaną bramkę webhook, która przejmie cały cykl życia wychodzącego. Powinna odbierać przychodzące zdarzenia z naszych usług, zapisywać je, a następnie wysyłać każde zdarzenie do wszystkich punktów końcowych subskrybujących ten typ, całkowicie oddzielając dostawę od kodu, który wygenerował zdarzenie.

Niezawodność jest kluczowa, więc najbardziej martwię się o awarie subskrybentów. Każda próba dostawy musi być podpisana, aby odbiorca mógł zweryfikować, że pochodzi od nas, zawierać znacznik czasu i unikalny identyfikator dostawy, aby chronić przed duplikatami, a w przypadku błędu ponawiać z wykładniczym opóźnieniem i jitterem do konfigurowalnego limitu, a następnie przechodzić do stanu martwego listu. Potrzebujemy limitów współbieżności na poziomie punktu końcowego, aby jeden przytłoczony subskrybent nie konsumował zasobów z reszty, oraz kluczy idempotencyjnych, aby ponowne próby nigdy nie powodowały duplikatów po stronie odbiorcy. Aby wyjaśnić zakres: to nie jest ogólna kolejka wiadomości do zadań wewnętrznych i nie jest to proxy bramy API dla przychodzącego ruchu. Chodzi o niezawodne dostarczanie wychodzących webhooków do stron trzecich, a kolejka jest tylko wewnętrznym mechanizmem, a nie wynikiem.

Potrzebuję również obserwowalności i zarządzania, które mogę przekazać wsparciu i partnerom. Każda próba powinna trafić do dziennika dostaw z żądaniem, kodem odpowiedzi, opóźnieniem i liczbą ponownych prób, możliwym do przeszukiwania według zdarzenia, punktu końcowego i statusu. Powinien być sposób na ręczne ponowne próby nieudanych lub martwych dostaw, wstrzymanie punktu końcowego i wznowienie go oraz rotację sekretów podpisywania bez przestojów. Proszę traktować to jako infrastrukturę produkcyjną — z jasną dokumentacją i testami, a nie prototypem.

— Punkt końcowy do odbierania przychodzących zdarzeń z walidacją i trwałością
— Model subskrypcyjny: dopasowywanie typów zdarzeń do punktów końcowych subskrybentów
— Podpisane ładunki z znacznikami czasu, identyfikatorem dostawy i ochroną przed duplikatami
— Ponowne próby z wykładniczym opóźnieniem, jitterem i stanem martwego listu
— Limity współbieżności na poziomie punktu końcowego i obsługa idempotencji
— Dziennik dostaw z wyszukiwaniem, ręcznymi próbami i wstrzymywaniem punktu końcowego
— Rotacja sekretów, dokumentacja i autotesty