„Realtime" w integracjach B2B to marketing, nie wymaganie

Co klient naprawdę mówi

Kiedy klient mówi „realtime", w 90% przypadków nie opisuje wymagania technicznego. Opisuje wspomnienie o awarii: kiedyś sprzedali towar, którego nie było, i ktoś musiał dzwonić z przeprosinami.

To jest istotne rozróżnienie, bo z „nie chcę sprzedać czegoś, czego nie mam" nie wynika „każda zmiana stanu w ERP ma być w sklepie w ciągu sekundy". Wynika z tego rezerwacja stanu w momencie składania zamówienia - co jest zupełnie innym problemem, znacznie tańszym i faktycznie rozwiązywalnym.

Pierwsze pytanie, które warto zadać, brzmi więc nie „jak szybko", tylko: co ma się nie wydarzyć.

Cztery rzeczy pod jednym słowem

Kiedy rozbijesz „realtime" na konkrety, prawie zawsze wychodzą cztery osobne wymagania o różnych progach:

Stan magazynowy. Realnie wystarcza kilka minut opóźnienia, pod warunkiem że w momencie dodania do koszyka i przy składaniu zamówienia robisz sprawdzenie na żywo. Ryzyko jest w oknie między jednym a drugim, nie w tym, że katalog pokazuje dane sprzed pięciu minut.

Cena kontraktowa. Tu opóźnienie jest akceptowalne w godzinach, bo cenniki zmieniają się rzadko. Nieakceptowalna jest natomiast niespójność: cena w koszyku musi być tą samą, która wyjdzie na fakturze. To wymaganie o spójności, nie o szybkości.

Status zamówienia. Klient B2B akceptuje, że status aktualizuje się co kilkanaście minut. Nie akceptuje, że status kłamie albo cofa się w czasie.

Limit kredytowy. To jedyne z tej czwórki, które zwykle naprawdę musi być sprawdzane na żywo - bo blokada ma zadziałać przed złożeniem zamówienia, a nie po. I dokładnie dlatego, że jest jedno, da się je zrobić dobrze.

Zauważ, że tylko jedno z czterech wymaga odpytania na żywo. Pozostałe trzy potrzebują przewidywalności, nie prędkości.

Dlaczego realtime jest drogi

Koszt „realtime" nie leży w szybkości. Leży w tym, co realtime robi z odpornością systemu.

Synchroniczne odpytywanie ERP-a przy każdym wyświetleniu produktu oznacza, że awaria ERP-a kładzie sklep. To nie jest teoretyczne: ERP-y bywają wyłączane na noc, na inwentaryzację, na aktualizację. Sklep, który bez ERP-a nie potrafi pokazać katalogu, jest sklepem z dwoma pojedynczymi punktami awarii zamiast jednego.

Do tego dochodzi rzecz, o której się nie mówi na spotkaniach sprzedażowych: licencje i limity sesji. Sfera Subiekta ma ograniczoną liczbę równoległych sesji. API większości polskich ERP-ów nie było projektowane pod ruch sklepowy. Realtime przy 50 użytkownikach naraz nie jest problemem architektonicznym - jest problemem umowy licencyjnej.

Czego używać zamiast

Wzorzec, który sprawdza się w większości polskich wdrożeń B2B, jest nudny i dlatego działa:

• Batch nocny na pełny katalog - wolno, kompletnie, bez pośpiechu.
• Delta co kilka-kilkanaście minut na to, co się zmienia (stany, ceny).
• Odpytanie na żywo w punkcie decyzji - przy dodaniu do koszyka i przy składaniu zamówienia, czyli dwa razy na sesję zamiast dwustu.
• Kolejka między sklepem a ERP-em, żeby awaria po tamtej stronie oznaczała opóźnienie, a nie błąd 500 u klienta. Rozwijam to w tekście o kolejkach.

Efekt: klient dostaje to, o co naprawdę prosił - nie sprzedaje czegoś, czego nie ma - a system przeżywa nocną aktualizację ERP-a.

Jeśli po tym rozbiciu zostaje realne wymaganie realtime, to znaczy, że jest prawdziwe i warto za nie zapłacić. Ale wtedy wiadomo, za co konkretnie się płaci, i nie jest to „bo tak było w briefie".

Decyzja, czy to wszystko spinać bezpośrednio, czy przez warstwę pośrednią, to osobna rozmowa - opisałem ją w tekście o middleware kontra integracja bezpośrednia.

Co dalej

• Jak odpiąć sklep od awarii ERP-a: Kolejki RabbitMQ i Redis
• Bezpośrednio czy przez most: Middleware vs. bezpośrednio
• Pełny przegląd integracji: pillar /integracje