Wzorzec projektowy Transactional Outbox

Cześć Wszyscy!

Ostatnio dużo słyszy się o wyzwaniach związanych z niezawodnością i komunikacją między mikroserwisami. Wiem, że dla wielu z Was, tak jak i dla mnie, jest to temat nie tylko ważny, ale i pełen niespodzianek.

Właśnie dlatego postanowiłem pogłębić temat i podzielić się z Wami swoimi odkryciami dotyczącymi wzorca "transactional outbox".

Znalazłem rozwiązanie, które może znacząco poprawić niezawodność naszych systemów. To nie tylko teoria, ale praktyczne podejście, które możemy zaimplementować w naszych projektach. W moim najnowszym wideo na YouTube szczegółowo omawiam:

Jak "transactional outbox" zapewnia atomowość transakcji i niezawodność komunikacji. 📦🔒
Praktyczne wskazówki dotyczące implementacji wzorca w różnych środowiskach. 🛠️
Rozwiązania typowych problemów i wyzwań, które możesz napotkać podczas pracy z tym wzorcem. 🚀

Uważam, że ta wiedza może być dla Was niezwykle cenna, niezależnie od tego, czy dopiero zaczynacie swoją przygodę z mikroserwisami, czy szukacie sposobów na optymalizację istniejących systemów.

Zapraszam Was serdecznie do obejrzenia wideo i podzielenia się swoimi doświadczeniami w komentarzach. Wasze opinie i spostrzeżenia są dla mnie niezwykle ważne!

Oto link do wideo: Kliknij

Jeśli znajdziecie wartość w treści, które tworzę, zachęcam do subskrypcji kanału – będzie mi niezmiernie miło.

Czekam na Wasze opinie i sugestie! Do zobaczenia w sekcji komentarzy!

Rozwlekles na 10 minut informacje, ktore byly do przekazania w polowe tego czasu jak nie krocej. Wszystko mowione jednym tonem i tempem, 70 letni wykladowcy na polibudzie ciekawiej przekazuja wiedze. Do tego ten poczatek polegajacy na klepaniu formulki.

Wisienka na torcie bylo omawianie "minusu" outboxa polegajacego na "nadmiarowej tabeli". To nie ma zadnego sensu, bo celem jest przeciez spojnosc danych, wiec pewnego rodzaju "overhead" zawsze musi wystapic.

Niestety nie urzeklo mnie to ani merytorycznie, ani pod wzgledem formy :(.

edit: Do tego nawet nie wspomniales (chyba, ze przegapilem za co przepraszam), ze outbox zapewnia AT LEAST once delivery co jest bardzo wazne w kontekscie przetwarzania danych.

Ja od siebie powiem tyle, że w 99% przypadków tam gdzie mikroserwisy są wprowadzane - to w ogóle nie są potrzebne. Ludzie jest wprowadzają bo jest hype.

Jednym z pomyslow autora bylo to zeby dwa serwisy (sklep i platnosci) komunikowaly sie przez wspolna tabele w bazie. Takze no, nic wiecej chyba dodawac nie trzeba :P

Niestety, ale nie zrozumiałeś idei tego wzorca. Te dwa serwisy nie komunikują się w żadnym razie za pośrednictwem jednej tabeli, to by przecież nie miało sensu. Do tabeli zapisujesz eventy, po to żeby w ramach jednej lokalnej transakcji wykonać operacje, co gwarantuje ci atomiczną operację.

Odnośnie opinii, że mikroserwisy są niepotrzebne w 99% przypadków to niestety ale też nie mogę się z tym zgodzić. Jest to wzorzec, którzy jest faktycznie popularny, jest drogi w utrzymaniu, ale jest on dedykowany dla dużych rozwiązań, które zakładają potrzebę skalowania.

@migatotech: wzorzec rozumiem doskonale, ponieważ w pracy cały system nad którym pracuję jest oparty na zdarzeniach :).
Odnoszę się do stwierdzenia z 5:30 w nagraniu. Sugerujesz żeby serwis płatności odpytywal bazę danych serwisu sklepu. Co jest dosłownie komunikacja za pomocą bazy danych, bo flow wtedy jest takie:
Sklep - > baza - > płatności.
Powiem więcej, jest to jeden z antywzorcow w architekturze mikroserwisow, ponieważ każdy z nich powinien mieć własną bazę. Serwisy te z definicji powinny cechowac się wysoką spójnością i niskim sprzężeniem. Jeżeli obydwa serwisy muszą korzystać ze wspólnej tabeli to tworzysz niepotrzebne sprzężenie i na 99% źle podzieliłeś system na mikroseriwsy.

Masz rację. Dziękuję, że obejrzałeś ten film tak dokładnie, zauważyłeś coś czego nawet nie byłem świadom, że powiedziałem.