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ę.