Procesowanie webhooków, a broker wiadomości

Mam serwis integrujący, który procesuje webhooki z kilku innych serwisów (docelowo 100+). Aktualnie wielkiej filozofii nie ma, przychodzi webhook, jest obsługiwany, coś tam zapisuje się do bazy, coś wysyła się do jeszcze innego serwisu i koniec, a z racji natury webhooka, żaden response zwrotny nie jest potrzebny.
Zastanawiam się czy tu jest miejsce na kolejną warstwę pośredniczącą w postaci brokera kolejkującego webhooki? Czyli przepływ byłby taki: webhook przychodzi do serwisu integrującego -> wrzucany jest na kolejkę -> serwis sobie w dogodnej chwili webhooki przetwarza zgodnie z istniejącą logiką. Uodparniamy się wtedy na "skoki" requestów, bo wrzucenie na kolejkę jest szybkie, a przetworzenie webhooka już niekoniecznie. No i niejako też możemy mieć za darmo mechanizm ponownego przetworzenia requestów bo wystarczy je ponownie zakolejkować po błędzie.
Ma to sens? Myślałem nad Rabbitem, ale z kolejkami za dużego doświadczenia nie mam, więc jeśli inne rozwiązanie by się nadało to chętnie wysłucham propozycji :)

Ma to sens jak masz problemy wydajnościowe, jak nie masz to zbędna komplikacja. Ja bym zaczął też od skalowania usługi, czyli load balancer i za nim kilka instancji jak nie ma znaczenia co do kolejności obsługi wywołań. Rabbit to dobra kolejka, ja sobie chwaliłem prace z nią, ale jak masz bazę juz jakąś użytą to możesz na początek tam zrobić kolejkę. To wszystko zleży co tam tak naprawdę się dzieje, jak szybko i czy jest z tym problem.

Tak, to standardowa procedura z uwagi na to, że kolejki dobrze współgrają z webhookami:

• upraszczamy do minimum kod webhooka
• nie gubimy żadnej wiadomości
• jak coś popsujemy to możemy naprawić buga w naszym kodzie i przepuścić wiadomość jeszcze raz

slsy napisał(a):

• jak coś popsujemy to możemy naprawić buga w naszym kodzie i przepuścić wiadomość jeszcze raz

Jak chcesz poprawiać logiczne błędy webhooka jak zużyjesz kolejkę? Równie dobrze można logować gdzieś wywołania.

S4t napisał(a):

slsy napisał(a):

• jak coś popsujemy to możemy naprawić buga w naszym kodzie i przepuścić wiadomość jeszcze raz

Jak chcesz poprawiać logiczne błędy webhooka jak zużyjesz kolejkę? Równie dobrze można logować gdzieś wywołania.

Ale czemu webhook miałby mieć jakąkolwiek logikę? Zwykle robi się tak, że endpoint webhooka po otrzymaniu wiadomości zapisuje ją gdzieś do przetworzenia (kafka, rabbitmq, czy choćby zwykła baza danych) i koniec, a osobny proces nazwijmy go handlerem przetwarza tą wiadomość wykonując jakąś logikę. Jak masz wiadomość na Kafce to możesz odczytać wiadomość i przetworzyć ją jeszcze raz i jeszcze raz i jeszcze raz... to samo w przypadku db bo wiadomość nie ginie, co najwyżej zmienia się w db jej status na processed. W przypadku rabbitmq jest trochę gorzej bo po przetworzeniu w odpowiedzi leci ACK do brokera i wiadomość znika z kolejki.

Tylko po co te dane trzymać na kafce? Ja mam tak w projekcie że ta sama logika jest wołana z różnych systemów w różny sposób. Raz to jest webhook raz zwykły API call czyli musiał bym utrzymywać dwa różne procesy. A wywołań jest około 10 może 20 dziennie.

S4t napisał(a):

Tylko po co te dane trzymać na kafce? Ja mam tak w projekcie że ta sama logika jest wołana z różnych systemów w różny sposób. Raz to jest webhook raz zwykły API call czyli musiał bym utrzymywać dwa różne procesy. A wywołań jest około 10 może 20 dziennie.

Ale tu dyskutujemy i rozważamy projekt OPa nie twój. W dodatku opierajac sie o dosc mgliste wymagania. Wiadome jest ze każdy projekt jest inny i trzeba podchodzić indywidualnie.

Kafka spełnia wszystkie twoje wymagania, nie pisałeś ich pod Kafkę specjalnie? ;)
Oczywiście trzeba to dobrze i z głową skonfigurować (retencje, partycje, consumer grupy, storage), ale jak ten krok przejdziesz to jest praktycznie bezobsługowy system. Można też potem w fajny sposób "niebezpośrednio" monitorować system, np. rosnący lag na konsumencie = system się zaciął, przyrost na DLT = system sypie błędami, tego typu rzeczy się przydają jak nie chce ci się pisać własnego monitoringu.

Dzięki za odpowiedzi, daję więcej kontekstu:

• procesowanie webhooka może trwać kilka milisekund, jak i sekundę,
• webhooki z jednego serwisu muszą być przetwarzane chronologicznie,
• do 200 requestów na dobę per serwis, jeśli skok to jednorazowo w stylu 5/s na 2 sekundy,
• musi być przetworzony szybko - najlepiej do kilku sekund,
• po błędnym procesowaniu, powinna zostać podjęta próba ponownego procesowania po jakimś czasie,
• logika możliwa jedynie do wykonania z webhooka.

Co do trzymania webhooków, dla aktualnego podejścia z bazą wygląda to w porządku, bo zapisujemy powód błędu, a w przypadku powodzenia - i tak zapisujemy wraz z webhookiem jakieś dodatkowe info, np. dlaczego pominięto procesowanie, więc ewentualny storage na plus. Wydaje mi się, że standardowe podejście jednak wystarczy, ale co wy myślicie?

S4t napisał(a):

Jak chcesz poprawiać logiczne błędy webhooka jak zużyjesz kolejkę? Równie dobrze można logować gdzieś wywołania.

Webhook nie ma logiki tylko zamienia request HTTP na message i wrzuca do kolejki. Dalej handler wiadomosci moze przeniesc wiadomosc do innej kolejki DLQ, jeśli wiadomość (lub kod) są niepoprawne

logika możliwa jedynie do wykonania z webhooka.

@kalee możesz rozwinąć? To brzmi dziwnie. Zawsze przecież możesz wydzielić część kodu odpowiadającą za logikę

slsy napisał(a):

S4t napisał(a):

Jak chcesz poprawiać logiczne błędy webhooka jak zużyjesz kolejkę? Równie dobrze można logować gdzieś wywołania.

Webhook nie ma logiki tylko zamienia request HTTP na message i wrzuca do kolejki. Dalej handler wiadomosci moze przeniesc wiadomosc do innej kolejki DLQ, jeśli wiadomość (lub kod) są niepoprawne

logika możliwa jedynie do wykonania z webhooka.

@kalee możesz rozwinąć? To brzmi dziwnie. Zawsze przecież możesz wydzielić część kodu odpowiadającą za logikę

To było nawiązanie do jednego z powyższych komentarzy: chodzi o to, że jedynym sposobem na wywołanie tej logiki jest przyjście webhooka.