Transactional outbox z Debezium pod spodem - używał ktoś?

Zacznę może od początku.

Po co mi outbox

Sytuacja jest raczej dość typowa - pewna operacja zmienia dane, wskutek zmiany powinien nastąpić zarówno zapis do lokalnej bazy, jak i wysłanie eventu. Dobrze by było wykluczyć choćby hipotetyczne sytuacje, gdy event leci a zapis do bazy się wysypuje (lub odwrotnie) i nie ma za bardzo jak tego automagicznie uprzątnąć, więc z początku rozważałem dwie opcje:

• transactional outbox i zapisywanie eventów do "loga" w bazie w ramach transakcji, dopiero stąd message relay wciąga eventy i wrzuca do kolejki
• event sourcing i traktowanie eventów jako źródła prawdy + sink do bazy do odczytu

Event sourcing wydawał się grubą przesadą jak na potrzeby projektu, więc odpadł właściwie z automatu. Poza tym w podejściu z outbox dodatkową zaletą byłaby możliwość utrzymania read-your-writes consistency - skoro baza pozostaje źródłem prawdy, nie byłoby problemu z ew. opóźnieniami. Tak czy siak wstępnie padło na outbox.

Po co mi Debezium

Żeby nie rzeźbić wszystkiego od zera i nie narobić tym sobie więcej potencjalnych bugów, niż gdybym nawet ogarnął temat "naiwnie" lub "pół-naiwnie" hakując coś w Springu, zacząłem szukać czegoś co by posłużyło za message relay. I znowu, uwagę zwróciły dwie opcje

• Eventuate
• Debezium

Oba wyglądają na niemałe krówska "prawie do wszystkiego", oba najwyraźniej dostarczają "coś" co pozwalałoby np. podpiąć się pod transaction log w bazie, wyciągnąć coś z tabelki outbox i wysłać event, no ale że eventuate jest chyba większe spośród dwóch krówsk i w dodatku bardziej niszowe (o ile gwiazdki na GH to dobra metryka - różnica prawie 10x), to wstępnie myślę o użyciu Debezium.

Pytania

Jeśli mieliście z tym do czynienia

• jak się sprawdzało?
• zauważyliście jakieś problemy, bolączki używając tego?
• jak to stawialiście - w wersji standalone (np. w kontenerze) czy embedded (w samej aplikacji)?
• w pierwszym przypadku, były problemy z podpięciem tego pod monitoring, health checki? Pół dnia szukam jakiejkolwiek dokumentacji API, które podobno jest, a dobrze by było mieć do tego przynajmniej readiness i liveness probe. Jedyne co jak dotąd znalazłem, to dzikie haki ze StackOverflow z one-linerami - tasiemcami i narzekanie, że w sumie te health checki by się przydały, bo połączenie do binlog MySQL czasami się to wywala ¯\_(ツ)_/¯
• w drugim przypadku, rozwiązanie embedded nie przeszkadza zbytnio w funkcjonowaniu aplikacji? Średnie by to było, gdyby aplikacja przestała obsługiwać żądania, bo wielce wysyłamy eventy
• może istnieją lepsze alternatywy?

Edit

Radosna menażeria stoi w klałdzie AWS

Napisanie własnego outboxa nie wymaga jakiegoś strasznego rzeźbienia, ani też za bardzo nie ma tam gdzie popełnić błędu, wydaje mi się że więcej problemów będzie z dostosowaniem jakiegoś zewnętrznego rozwiązania do potrzeb.

neves napisał(a):

Napisanie własnego outboxa nie wymaga jakiegoś strasznego rzeźbienia, ani też za bardzo nie ma tam gdzie popełnić błędu, wydaje mi się że więcej problemów będzie z dostosowaniem jakiegoś zewnętrznego rozwiązania do potrzeb.

Prawdę mówiąc obecne potrzeby nie są szczególnie wyszukane - po prostu nie chcemy sytuacji, gdy permanentnie zgubią się albo zmiany w bazie, albo event, bo byłoby to dość uciążliwe.

Z jednej strony masz rację, z drugiej - popraw mnie jeśli się mylę, ale taka najbardziej naiwna implementacja outboxa i tak byłaby w stanie gubić eventy, gdyby jednak nie udało się ich wysłać, więc w sumie nie byłoby wcale lepiej niż bez niego. Potrzeba przynajmniej trzymać "gdzieś" offset, do którego można w razie draki wrócić i zagwarantować dostarczanie przynajmniej raz.

Druga kwestia, co do której mam obawy, to to czym się może skończyć rzeźbienie własnych rozwiązań. My sobie przyspawamy outboxa gdzieś z tyłu aplikacji, zaraz drugi i trzeci zespół stwierdzi, że im outbox potrzebny i albo przyspawają własne - i w ten sposób każda aplikacja będzie miała swoją implementację z własnymi smaczkami - albo będziemy rzeźbić firmową bibliotekę / framework do robienia outboxów i się z nią męczyć. To już wolę wziąć coś, co już istnieje i nie jest noname z 1 maintainerem - i w razie czego móc do tego odesłać ;)

Nawiasem mówiąc, walczyłem w międzyczasie z wepchnięciem tego ustrojstwa bezpośrednio do aplikacji (przez Debezium engine), ale pokonało mnie i samo siebie dokumentacją 2/10 i wynikającym z tego dość upierdliwym setupem, polegającym głównie na zgadywaniu, czy toto się konfiguruje tak samo jak wersję standalone na Kafka Connect. A że dokumentacja dla connectora wrzucanego do Kafka Connect wydaje się troszeczkę lepsza, to pewnie niedługo będę się z tym siłował.

taka najbardziej naiwna implementacja outboxa i tak byłaby w stanie gubić eventy, gdyby jednak nie udało się ich wysłać

Możesz podać przykład scenariusza kiedy by to nastąpiło? Prostą implementacją byłoby np. wysyłanie eventów z event loga i oznaczanie ich jako wysłanych/kasowanie dopiero jak otrzymasz potwierdzenie, że zostały wysłane. Gdzie tu jest dziura?