Zdarzenia, powiadomienia i odzyskiwanie

Problem#

Marketplace składa się z operacji, które dotykają kilku systemów naraz: płatność, zamówienie, powiadomienie, wypłata, integracja. Każda z nich może zawieść osobno, a najgorszy przypadek nie jest awarią całości, tylko sukcesem połowicznym.

Pieniądze pobrane bez zamówienia, zamówienie bez powiadomienia, zwrot wykonany u dostawcy i nieodnotowany u siebie. Te sytuacje są rzadkie i pewne.

Zasada#

Minimalna wersja#

• Logi z identyfikatorem operacji, po którym da się połączyć wpisy w jedną historię.
• Widoczność nieudanych zadań w tle, choćby jako lista do przejrzenia.
• Rejestr zdarzeń przychodzących od dostawców, z ich identyfikatorami.
• Możliwość ręcznego powtórzenia operacji, bez skutków ubocznych przy powtórzeniu.

Powiadomienia#

Wysyłka e-maila jest osobną operacją od zdarzenia biznesowego, które ją wywołało. Ich sklejenie powoduje dwa problemy naraz: awaria poczty blokuje sprzedaż, a udana wysyłka wygląda na dowód, że reszta się udała.

• Zdarzenie biznesowe zapisuje się niezależnie od tego, czy powiadomienie wyszło.
• Nieudana wysyłka jest ponawiana, a po wyczerpaniu prób zostaje widoczna, nie znika.
• Brak powiadomienia nigdy nie blokuje operacji, której dotyczy.

Czego nie budować teraz#

• Centrum powiadomień z preferencjami użytkownika.
• Pełnego śledzenia rozproszonego z korelacją między usługami.
• Automatycznej naprawy rozbieżności.
• Alertów na wszystko. Alert, który dzwoni codziennie, przestaje być alertem.

Zaplanuj z góry#

Identyfikator operacji przechodzący przez wszystko#

Jeden identyfikator nadany na wejściu i przekazywany dalej pozwala później odtworzyć, co się wydarzyło. Dodanie go po fakcie nie da się zastosować wstecz do zdarzeń, które już zaszły.

Nieudane zadania zostają, nie znikają#

Domyślne zachowanie wielu kolejek to usunięcie zadania po ostatniej nieudanej próbie. Wtedy nie ma czego oglądać. Zadanie, które przepadło, jest gorsze niż zadanie, które widocznie nie wyszło.

Rozbieżność jako coś, co się mierzy#

Porównanie własnego zapisu z danymi dostawcy nie musi być automatyczne. Musi być możliwe. Nawet zestawienie robione raz w tygodniu ręcznie jest nieporównywalnie lepsze niż odkrycie rozbieżności trzy miesiące później.

Wyzwalacze#

• pierwsza płatność bez zamówienia;
• pierwsze pytanie, czy powiadomienie w ogóle wyszło;
• pierwsza rozbieżność w kwotach;
• pierwszy przypadek, w którym powtórzenie operacji zrobiło coś dwa razy;
• awaria dostawcy, po której nie wiadomo, co przeszło, a co nie.

Następny etap#

Po pierwszym i trzecim wyzwalaczu: zestawienie rozbieżności, ręczne. Po drugim: historia wysyłek powiadomień. Po czwartym: idempotencja tam, gdzie jej brakuje, priorytetowo w operacjach pieniężnych. Po piątym: dopiero wtedy alerty, i tylko na to, na co ktoś faktycznie zareaguje.

Częste błędy#

Co się sprawdza w praktyce#

Najwięcej spokoju dało to, żeby nieudane zadania w tle zostawały widoczne zamiast znikać. Domyślne ustawienia kolejek często je usuwają, przez co awaria dostawcy poczty albo chwilowy problem z bazą kończy się cichą utratą powiadomienia, o której dowiadujesz się od klienta.

Druga rzecz: rejestr zdarzeń przychodzących. Odpowiada jednocześnie na pytanie, czy coś dotarło, i chroni przed przetworzeniem tego samego dwa razy. Trudno wskazać tańszy element o tak dużym wpływie na spokój przy operacjach pieniężnych.

Checklista#

• Operacja ma identyfikator przechodzący przez logi i zadania.
• Nieudane zadania są widoczne, nie usuwane.
• Zdarzenia przychodzące mają rejestr z identyfikatorem dostawcy.
• Powtórzenie operacji pieniężnej nie wykonuje jej drugi raz.
• Powiadomienie nie blokuje operacji, której dotyczy.
• Istnieje sposób porównania własnych danych z danymi dostawcy.