Subskrypcje i rozliczenia za faktyczne użycie

Kłopot zaczyna się w dniu, w którym księgowość pyta, dlaczego suma z raportu nie zgadza się z sumą z rachunków, albo klient dzwoni z pytaniem o jedną pozycję. Musisz wtedy pokazać zapis tego, co się wydarzyło, zdarzenie po zdarzeniu, komuś, kto ma wszelki interes w tym, żeby znaleźć w nim dziurę.

To problem porządku w danych, a nie cennika. Trudność jest przy tym na tyle zwyczajna, że łatwo ją zlekceważyć: to samo zdarzenie przyjdzie dwa razy. Sieć ponawia. Funkcja bywa ubita w połowie żądania i uruchomiona od nowa. Kolejka dostarcza ponownie, bo zgubiło się potwierdzenie, a nie sama wiadomość. Każdy z tych przypadków zamieniony w drugą opłatę to w najlepszym razie zgłoszenie do wsparcia.

Istotne jest to, co dzieje się z tym kluczem dalej. Staje się kluczem głównym wiersza, zamiast leżeć w osobno indeksowanej kolumnie sprawdzanej przed zapisem. Ta różnica jest całym mechanizmem: duplikat odrzuca sama baza, w ramach tego samego zapisu. Nie ma okna między sprawdzeniem a zapisem, przez które przecisnęłoby się równoległe ponowienie, i nie ma osobnej usługi deduplikującej, którą trzeba utrzymywać przy życiu.

Cena tego rozwiązania jest realna i stoi w dokumentacji zamiast siedzieć w przypisie. Dwa naprawdę różne zdarzenia, identyczne co do milisekundy, zlewają się w jeden wiersz. To świadome niedoliczenie. Skoro system rozliczeniowy musi się czasem mylić, niech myli się w stronę, której klient nie zobaczy na wyciągu.

Partia opuszcza bufor, gdy się zapełni, domyślnie przy 500 zdarzeniach, albo gdy najstarsze zdarzenie w niej doczeka interwału zrzutu, domyślnie pięciu sekund. Przy dziesięciu tysiącach zdarzeń w buforze włącza się wstrzymanie. Partia, której nie udało się zapisać, wraca na początek kolejki, a nie na koniec, więc chwilowa awaria nie przestawia po cichu kolejności dziennika. Niezależnie od tego zadanie cykliczne zrzuca bufor co minutę, co ratuje sytuację przy małym ruchu, gdzie partia potrafiłaby stać w połowie pełna.

Bufor żyje w pamięci. Twarde ubicie procesu gubi to, co nie zdążyło się zapisać, chyba że włączysz tryb natychmiastowego zrzutu. Ten wybór zostawiamy Tobie, osobno dla każdego licznika. Licznik o dużym wolumenie zwykle woli bufor, a licznik czegoś rzadkiego i drogiego zwykle nie.

Taryfikacja korzysta z taryfy, w której siedzi kwota jednostkowa, dzielnik jednostek dla liczników mierzonych naturalnie w tysiącach czegoś oraz pula wliczona w abonament. Zamknięcie okresu zamraża wynik i dopiero to zamienia rosnącą sumę w liczbę, którą wypada komuś wysłać.

Korekty są dopisywane, nigdy nakładane na istniejący wpis. Pomyłkę naprawia się wpisem storno z ujemną ilością, więc w dzienniku zostaje zarówno pierwotne wskazanie, jak i późniejsza decyzja o nim.

Jedną granicę warto postawić od razu, zamiast zostawiać Cię z odkrywaniem jej w trzecim tygodniu. medusa-usage nie wystawia faktur i nie ma w niej harmonogramu zamykania okresów. Produkuje zamrożone wyniki okresów, przeliczone według taryfy. Zamiana ich w dokumenty i płatności to osobny zakres, który chętnie zbudujemy, ale nie udajemy, że jest już w pudełku.

Dla takich przypadków medusa-usage-tinybird wysyła te same zdarzenia do Tinybird na ClickHouse. Schemat wtyczka wnosi ze sobą, jedno źródło danych i trzy endpointy, więc nie dostajesz w prezencie projektu modelowania danych. Instalacja jest opcjonalna, a wdrożenie, które jej nie zakłada, nie zmienia się ani trochę.

ClickHouse nie zna ograniczenia klucza głównego, więc deduplikacja musi się gdzieś przenieść i przenosi się na odczyt. Każdy endpoint scala duplikaty przed sumowaniem i zostawia najwcześniej zapisaną kopię. Dokładnie tę samą kopię trzyma zapis w PostgreSQL, więc oba dają ten sam wynik z założenia, a nie przez przypadek. Deklarowany token ma prawo dopisywania do źródła danych i odczytu z endpointów, i nic ponadto.

Budujemy ją z trwałym outboxem. Każda partia trafia do outboxu przed pierwszą próbą wysyłki, więc funkcja ubita w połowie żądania kosztuje opóźnioną dostawę, a nie dziurę w dzienniku. Godzinowe zadanie dobiera to, czego próba w locie nie dokończyła, dzięki czemu odzyskiwanie danych jest rutyną, a nie śledztwem.

Druga zasada mówi, że jedynym miejscem wyliczania klucza deduplikacji jest Medusa. Aplikacja raportująca nigdy nie dopisuje do dziennika bezpośrednio, więc klucz powstaje w jednym miejscu. Dwa wyliczenia to dwie szanse na rozjazd, a rozjazd w kluczu deduplikacji nie należy do błędów, które znajduje się szybko.

Nie jest to rysunek z oferty. Tak zbudowane jest rozliczanie subskrypcji i zużycia naszej własnej platformy, na sklepie Medusa, który hostujemy sami.