Session

Outbox Pattern: kiedy ten strzał do API to jednak za mało

I znowu ten moment: w swoim procesie wywołujesz API zewnętrznego systemu. Co robisz? Jeśli jest piątek popołudniu - wołasz synchronicznego POSTa i super :) Implementacja prosta, szybka, testy implementujesz błyskawicznie.

Ale w weekend nie odpoczniesz. Bo przecież co jak POST nie dojdzie bo sieć zawodna. A Ty już po swojej stronie zrobiłeś commit nowego rekordu w bazie. A jak POST dojdzie, ale będzie długo? User będzie czekał na UI a przecież co go interesuje że pod spodem jakiś zewnętrzny system jest powolny. No chyba w poniedziałek trzeba będzie doczytać o tych rozproszonych transakcjach i Two-phase commit. I już wiesz że kawa się będzie lała strumieniami.

Opowiem o komunikacji asynchronicznej z zachowaniem spójności końcowej z użyciem wzorca integracji Outbox. Sprawdza się gdy zmiana musi się zakomitować w kilku systemach które pojedynczo może i są transakcyjne, ale jako całość nie są. Zmiana zapisuje się do bazy ale musi trafić też na kolejkę? A co jak zapiszesz na kolejkę ale transakcja na bazie się nie powiedzie? Trzeba rollbackować z kolejki? Oby tylko ta wiadomość jeszcze tam była, prawda? :)

Historia oparta na case-study integracji systemów rożniących się od siebie. Wymienię jakie problemy dzięki Outbox macie rozwiązane za darmo, a jakie problemy wygenerowane. Też za darmo :) Po to abyś wiedział i świadomie podjął decyzję.

audience: Developers, Architects (Intermediate)

Jacek Milewski

Trener IT | Architekt DDD | Programista | Konsultant | Prelegent | Mentor

Warsaw, Poland

Actions

Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top