Errors, errors everywhere!

Pewnego razu grupa programistów zdecydowała się, że zgodnie z aktualnie panującymi na rynku trendami nie będą już pisać "monolitów". Wybrali kilka popularnych wzorców architektury (takich jak CQRS, Microservices, EDA, Event Sourcing) i zastosowali je w swoim produkcie. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, który bardzo ich cieszył wzrósł również diametralnie koszt infrastruktury, a obsługa błędów stała się koszmarem- serwisy padały w bliżej nieokreślonych momentach, połączenie sieciowe nie zawsze było stabilne, bazy danych traciły dane, a obsługa rozproszonej transakcji przyprawiała o ciężki ból głowy i pozbawiała weekendów.

Byłeś tam może?

Chciałbym opowiedzieć o praktykach obsługi błędów. Jak radzić sobie z problemami biznesowowymi w systemach asynchronicznych? Jak obsługiwać wyjątki nie tracąc danych klientów? Jak wiele razy można próbować ponowić konkretną operację? Na te pytania nie ma jednej dobrej odpowiedzi, warto zatem poznać więcej niż jedno potencjalne rozwiązanie. Historia o tym co może się nie udać w naszej wspanaiałej, skalowalnej, rozproszonej aplikacji.