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”…
Warto przy tym od razu postawić jednocześnie drugie pytanie o wpływ takiego zjawiska na działanie konkretnego systemu. Choć pozornie brzmi to irracjonalnie, ale nie każda wiadomość musi dotrzeć do miejsca przeznaczenia, czy zostać tam przetworzona tylko i wyłącznie jeden raz. W wielu przypadkach pominięcie aktualizacji widoku w asynchronicznej projekcji czy brak zwiększenia metryki zapewniającej observability aplikacji nie wydaje się większym problem… Oczywiście pod warunkiem, że są to sytuacje wyjątkowe, a przetwarzanie kolejnych zdarzeń przywróci właściwy stan.
Michał Ostruszka w dzisiejszej rozmowie zarysowuje kilka wzorców w kwestii gwarancji dostarczania wiadomości, które obok Outbox Pattern warto mieć w swojej architektonicznej skrzynce z narzędziami.
