Stany magazynowe

Problem#

Stan magazynowy wygląda na liczbę przy produkcie. Przestaje nią być przy pierwszym koszyku, bo między dodaniem do koszyka a zapłatą towar musi być dla kogoś zarezerwowany, a przy pierwszej integracji, bo liczba zaczyna pochodzić z zewnątrz.

Marketplace dokłada trzecią komplikację: stan ma właściciela. Dwóch sprzedawców może oferować ten sam przedmiot i to są dwa niezależne stany, nawet jeśli kupujący widzi jedną ofertę.

Minimalna wersja#

• Stan jest przypisany do wariantu i do sprzedawcy, nie do produktu.
• Rezerwacja jest osobnym pojęciem od ilości dostępnej, z własnym czasem życia.
• Dostępność to wynik odejmowania rezerwacji od ilości, liczony przy odczycie.
• Sprzedaż zmniejsza ilość, a nie tylko zwalnia rezerwację.

Czego nie budować teraz#

• Procesów magazynowych: przyjęć, przesunięć i inwentaryzacji. Sam wymiar lokalizacji zwykle dostajesz od platformy, ale operowanie kilkoma miejscami to osobna praca.
• Systemu przyjęć, przesunięć i inwentaryzacji. To osobny produkt, nie moduł marketplace.
• Prognozowania i punktów zamówienia.
• Rezerwacji rozproszonych między systemami. Rezerwuj u siebie, synchronizuj ilość.

Zaplanuj z góry#

Lokalizacja od pierwszego dnia, nawet jedna#

Stan przypisany do pary wariant i lokalizacja kosztuje dziś jedno pole, przy jednej lokalizacji dla każdego sprzedawcy. Dorobienie lokalizacji później oznacza migrację wszystkich stanów i wszystkich rezerwacji, w tym otwartych.

Źródło stanu jako informacja przy rekordzie#

Stan może pochodzić z ręcznej edycji, z importu albo z synchronizacji. Zapisanie, skąd wzięła się bieżąca wartość, kosztuje jedno pole, a bez niego pierwszy spór o to, dlaczego stan się zmienił, jest nierozstrzygalny.

Zmiany jako operacje, nie nadpisania#

Jeżeli stan jest tylko liczbą nadpisywaną w miejscu, dwa równoczesne zamówienia potrafią go rozjechać. Zmiana wyrażona jako operacja na wartości, wykonana atomowo, kosztuje tyle samo, a znosi całą klasę problemów z równoległością.

Wyzwalacze#

• pierwsza sprzedaż towaru, który się skończył;
• sprzedawca zgłasza, że stan jest niższy, niż powinien, bez sprzedaży;
• sprzedawca chce wysyłać z dwóch miejsc;
• sprzedawca podpina sklep i chce, żeby stany się zgadzały;
• ten sam towar zaczyna się sprzedawać w dwóch kanałach naraz.

Następny etap#

Po pierwszym wyzwalaczu: walidacja przy tworzeniu zamówienia i jawny komunikat. Po drugim: podgląd historii zmian stanu, żeby dało się odpowiedzieć na pytanie sprzedawcy. Po trzecim: druga lokalizacja, co jest tanie, jeśli model miał ją od początku. Po piątym: rozstrzygnięcie, czy platforma jest źródłem prawdy dla stanu, czy tylko go odzwierciedla.

Częste błędy#

Co się sprawdza w praktyce#

Wzorzec, który sprawdza się przy każdej wartości zmienianej równolegle, jest ten sam: zapis wyrażony jako operacja na wartości zamiast odczytu, przeliczenia i zapisu. Zamówienie obejmujące kilku sprzedawców tworzy kilka równoczesnych zmian tej samej liczby, a przy odczycie i zapisie część z nich po prostu ginie. To różnica kilku linii i znosi problem, który pojawia się losowo i jest trudny do odtworzenia.

Druga obserwacja dotyczy samego wymiaru lokalizacji. Był dostępny od początku i najtańszą decyzją okazało się po prostu z niego korzystać, zamiast spłaszczać stan do pojedynczej liczby przy produkcie. Prowadzenie kilku miejsc wysyłki jako proces operacyjny pozostało niepotrzebne znacznie dłużej, ale wymiar był na swoim miejscu w dniu, w którym się przydał.

Checklista#

• Stan należy do wariantu i sprzedawcy, nie do produktu.
• Rezerwacja jest osobnym pojęciem i wygasa.
• Dostępność jest liczona, nie przechowywana jako druga liczba.
• Zmiana stanu jest operacją atomową, nie nadpisaniem odczytanej wartości.
• Model dopuszcza drugą lokalizację, nawet jeśli dziś jest jedna.
• Wiadomo, czy sprzedaż ponad stan jest dozwolona, i gdzie to jest sprawdzane.