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 wzorców architektury (CQRS, Microservices, EDA, Event Sourcing) i zastosowali je. Po wdrożeniu okazało się, że wraz ze wzrostem skalowalności, wzrósł również koszt infrastruktury- 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 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 nie tracić 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ć i jak pisać system, który zareaguje na błędy gdy już się pojawią. Bo tego możesz być pewny- pojawią się.