Rozpraszanie systemu na szereg działających niezależnie od siebie usług, przy wszystkich oczywistych korzyściach dla ogólnej architektury i współpracy pomiędzy zespołami, niesie za sobą kilka istotnych konsekwencji. Przykładowo, dostarczenie zdarzenia czy innego komunikatu pomiędzy serwisami przestaje być już tak oczywiste i bezproblemowe, jak to jest w przypadku monolitycznych aplikacji komunikujących się wewnątrz in-memory.
Sieć ze swojej natury bywa zawodna, przerwa w dostarczaniu wiadomości, czy też dostarczanie ich do konsumentów w losowej kolejności nie są sytuacjami czysto hipotetycznymi. Wcześniej czy później taka sytuacja przydarzy się w systemie, pytanie brzmi tylko “kiedy”…
W tym odcinku rozmawiamy z Grzegorzem m.in. o:
👉 eventach wartych przesyłania pomiędzy usługami w systemie
👉 identyfikatorach wiadomości i finger printingu komunikatów
👉 problemach związanych z wykorzystaniem wzorców Transactional Outbox / Inbox
👉 wzorcu Change Data Capture i przesyłaniu zmian z poziomu bazy danych
👉 wzorcu Listen To Yourself i problemach związanych z zachowaniem spójności przy jego wykorzystaniu
👉 zapewniania sekwencyjności zdarzeń po stronie konsumenta
👉 prostym ćwiczeniu architektonicznym, za pomocą którego można wykryć potencjalne problemy na warstwie komunikacyjnej systemu
Materiały, o których wspominamy w trakcie rozmowy są udostępnione na stronie podcastu https://bettersoftwaredesign.pl/podcast/o-dostarczaniu-eventow-w-systemach-rozproszonych-z-michalem-ostruszka/
A jeżeli chcesz więcej, to polecam Ci odwiedzić moje miejsca w Internecie:
👉 https://bettersoftwaredesign.pl, podcast o architekturze i projektowaniu oprogramowania
👉 https://twitter.com/mariuszgil, dev profil na Twitterze
👉 https://www.instagram.com/mariuszgil_dev/, dev profil na Instagramie, gdzie jestem ostatnio wyjątkowo aktywny
