DevTalk #138 – O Event-Driven Architecture z Tomaszem Stolarczykiem

Co to, jak mówiłeś, może upraszczać, nie? Ale też jakby z technicznego punktu widzenia to wymaga pewnej takiej komplikacji jednak, żeby zaimplementować te mechanizmy wszystkie. To znaczy upraszcza pod warunkiem, że to jest zaopiekowane. No właśnie, tutaj dochodzimy w sumie do takich trzech trybów dostarczania, które często gdzieś tam się pojawiają, jak jest rozmowa o Event-Driven Architecture, czyli At Least Once Delivery, At Most Once Delivery i Exactly Once Delivery. I to też trzeba mieć gdzieś tam, mówię, w głowie, nagle. Znaczy to tak, nie wiem, trochę brzmi jakbyśmy trochę odradzali chyba, bo jest dużo rzeczy, którymi się trzeba zaopiekować. No to w sumie ważniejsze niż mówienie na hura, róbcie, róbcie, tylko raczej właśnie fajnie jest pokazać, z czym to się wiąże, co nie? Że są te benefity. Ale swoje trzeba zaorać, przeorać, przerobić. Dokładnie, dokładnie, dokładnie.

No i właśnie jeśli mamy takie, znaczy możemy rozróżnić takie trzy tryby dostarczania ogólnie, jeśli chodzi o jakiś tam messaging. I pierwszym jest taki Atmos Delivery. Atmos Once Delivery, tak. Atmos Once Delivery, który mówi, że wiadomość możemy dostać zero albo jeden raz. Że albo udało się opublikować, albo się nie udało i jak się udało to dostałeś i będziesz przetwarzał, jak się nie udało to nie dostaniesz, nie będziesz przetwarzał. Dla mnie to jest jakby tutaj jakby patrząc na to, że mamy Event-Driven Architecture, czyli mamy architekturę, w której kluczowe są eventy, to w ogóle powinniśmy ten tryb dostarczania jakby wykluczyć. No bo co to znaczy dla mnie to, że okej, coś się ważnego w systemie zmieniło, ja powinienem jakoś na to zareagować, a ja może dostanę, a może nie dostanę.

Tutaj już na poziomie jakby samego założenia jest to trochę bez sensu. Potem moglibyśmy z kolei powiedzieć exactly once delivery, czyli że na pewno dostaniesz tylko raz. Ale czekaj jeszcze chwilę, no i to się konfiguruje co, na tym pośredniku, na tej kolejce, która dystrybuuje te eventy, czy jak? Czy to jest konfiguracja systemu i na jakiej podstawie w ogóle taką decyzję się podejmuje? Na poziomie infrastruktury po części, ale po drugie też jakby np. wracając do samej publikacji, no to jeśli nie miałbyś, jeśli byś tylko robił tak, że Ty próbujesz wrzucić na kolejkę Jakby nie dbasz o to, czy to poszło, czy się udało, czy się nie udało, czy jakby wiesz, nie masz nawet takiego, wiesz, jakby outbox patternu zaimplementowanego, gdzie ten, który potem wysyła, publikuje te wiadomości, czyli tam gdzieś w tym outbox patternie też, Ty jakby musisz

Jakby, wiesz, zrobić acka, że ja wysłałem ten event, nie? Czyli, że ja go zrobiłem. Czyli próbujesz go wysłać do momentu, aż go wyślesz. Mógłbyś z drugiej strony nie mieć, nie wiem, outboxu i mógłbyś na przykład zmieniać stan w systemie, a wysyłać poza, nie? Czyli zrobić publisha na kolejkę, robić poza transakcją. Czyli faktycznie twojego flow by nie wywaliło, ale z drugiej strony... Byś miał tak, że może ci się udało wysłać, może ci się nie udało wysłać. Czyli z jednej strony jest to jakaś tam odpowiedzialność dostarczania już potem po stronie kolejki, ale z kolei po twojej stronie, czyli gdzieś tam w momencie, gdzie tam gdzieś ten Outlook z Patron sobie implementujesz, to jest taka odpowiedzialność, że ty musisz zadbać o to, że ten event zostanie wysłany. Exactly once z kolei odrzucamy raczej z praktycznych powodów, bo jest mało osiągalne czy właśnie praktyczne.

Bo to by wymagało od Ciebie takiego myślenia, że po pierwsze robisz tego acca, że to by się udało wysłać, a po drugie dobrze by było mieć jeszcze takiego acca, że to by się udało też przetworzyć. Jak wiesz, że to by się udało przetworzyć, to Ty raz mogłeś wykonać to coś. Ale to jest jakby wtedy trochę takie, wiesz, implementowanie rozproszonej transakcji, czego ja osobiście nie chciałbym robić. I po co mam mieć ten coupling taki, że wiem, że to musiało się wysłać, to musiało się jakby, wiesz, przetworzyć i dopiero wtedy uznaję, że zostało, wiesz, raz dostarczone, zostało przetworzone i jest okej. Dlatego jakby idziemy w ten trzeci tryb najczęściej, czyli to jest at least once delivery. Czyli znowu, by default ty musisz myśleć o tym, że ty z jakiegoś powodu możesz dostać wiadomość dwa razy.