Kiedy podzielić monolit sprzedaży internetowej na mikroserwisy NestJS?
Krótka odpowiedź: nie dziel monolitu sprzedażowego dlatego, że mikroserwisy brzmią nowocześnie. Dziel wtedy, gdy obsługa zamówień, płatności, rezerwacja stanów, system finansowo-magazynowy lub generowanie dokumentów zaczynają blokować finalizację zamówienia, rytm publikowania zmian albo skalowanie. Najbezpieczniejszy pierwszy krok to stopniowe przejmowanie przepływu zamówień: NestJS jako usługa zamówień, PostgreSQL jako własny model transakcyjny, RabbitMQ, Redis albo Kafka dla zadań pobocznych i jasny plan wycofania zmian.
Najpierw niewygodna prawda: mikroserwisy nie naprawiają złej domeny
Najdroższy błąd przy modernizacji sprzedaży internetowej nie polega na tym, że firma za długo trzyma monolit. Częściej polega na tym, że zbyt wcześnie rozcina system, którego nikt dobrze nie rozumie. Wtedy zamiast jednego trudnego wdrożenia powstaje kilka trudnych wdrożeń, kolejki, ponowienia, wersjonowanie umów między systemami, obserwacja działania i nowe miejsca awarii.
Dlatego dobry artykuł o mikroserwisach musi zaczynać się od pytania "po co?", a nie "jakiego brokera użyć?". Jeżeli finalizacja zamówienia działa, zespół szybko wydaje zmiany, a największym problemem jest bałagan w kodzie, zacznij od modularnego monolitu, testów i granic obszarów biznesowych. NestJS świetnie się do tego nadaje, bo moduły, wstrzykiwanie zależności i TypeScript pomagają uporządkować zaplecze bez natychmiastowego rozpraszania systemu.
Mikroserwis ma sens dopiero wtedy, gdy jeden obszar ma inne wymagania niż reszta aplikacji: obsługa zamówień musi przetrwać szczyty ruchu, płatności wymagają osobnych ponowień i bezpiecznego ponawiania operacji, system finansowo-magazynowy spowalnia finalizację zamówienia, dokumenty PDF blokują zasoby, a każde wydanie katalogu wymaga pełnej regresji zamówień. Wtedy nie "przepisujesz monolit na mikroserwisy". Wydzielasz jeden biznesowo krytyczny przepływ.
Sygnały, że obsługa zamówień powinna wyjść pierwsza
W sprzedaży internetowej pierwszym kandydatem do wydzielenia rzadko jest osobna usługa użytkowników albo produktów. Najczęściej jest nim przepływ zamówienia, bo bezpośrednio dotyka przychodu, magazynu, płatności, faktury, wiadomości do klientów, zwrotów, bazy klientów i systemu finansowo-magazynowego. Jeżeli tutaj awaria jednego dodatku zabija sprzedaż, koszt architektury rozproszonej zaczyna być uzasadniony.
Najmocniejszy sygnał to awaria poboczna blokująca finalizację zamówienia: wolny generator faktur, opóźnione połączenie z systemem finansowo-magazynowym, problem z wysyłką wiadomości albo przeciążony moduł promocji. Drugi sygnał to skalowanie nierówne: koszyk i zamówienia potrzebują więcej mocy obliczeniowej, kolejek oraz dokładniejszego wglądu w działanie niż reszta aplikacji. Trzeci sygnał to ryzyko wydania: zespół boi się wdrożyć zmianę w katalogu, bo może ruszyć płatności.
Czwarty sygnał jest organizacyjny: przepływ zamówienia ma właściciela biznesowego, osobne wskaźniki sukcesu i oddzielną listę zadań. Jeżeli szef sprzedaży internetowej, operacje i finanse spotykają się co tydzień wokół błędów w zamówieniach, to masz wyraźny obszar biznesowy. Jeżeli tylko "kod jest brzydki", jeszcze go nie masz.
- Finalizacja zamówienia zależy natychmiast od systemu finansowo-magazynowego, dokumentów PDF, wiadomości do klientów albo systemu magazynowego.
- W szczytach ruchu pada tylko część zamówieniowa, ale trzeba skalować cały monolit.
- Zmiany w promocjach, płatnościach lub fakturach wymagają pełnej regresji platformy.
- Błędy zamówień są mierzalnym kosztem: utracone płatności, ręczne korekty, reklamacje, opóźnione wysyłki.
Kiedy zostać przy monolicie
Martin Fowler opisał zasadę Monolith First: wiele udanych historii mikroserwisów zaczynało się od monolitu, który urósł i został rozbity, a wiele systemów zaczynanych od mikroserwisów od razu kończyło w poważnych problemach. To nie jest argument przeciw mikroserwisom. To ostrzeżenie przed płaceniem premii za rozproszoną architekturę, zanim firma ma stabilne granice domenowe i operacyjną dojrzałość.
Zostań przy monolicie, jeżeli masz mały zespół, niski wolumen zamówień, niewiele połączeń z innymi systemami, prostą finalizację zamówienia i brak realnej presji na niezależne wdrożenia. W takim układzie lepiej podnieść jakość monolitu: wydzielić moduły w NestJS, uporządkować transakcje, dodać testy umów między systemami, wynieść działania poboczne do kolejek i poprawić widoczność całej ścieżki zamówienia.
To jest często najlepszy wynik krótkiego rozpoznania przed kodem: nie projektujemy od razu pięciu usług, tylko ustalamy, czy problem dotyczy granic biznesowych, wydajności, organizacji czy po prostu jakości kodu. Czasem klient potrzebuje dwóch krótkich etapów porządkowania finalizacji zamówienia, a nie sześciomiesięcznej migracji.
Dlaczego NestJS pasuje do bezpiecznej ekstrakcji
Dokumentacja NestJS definiuje mikroserwis jako aplikację używającą transportu innego niż HTTP i pokazuje obsługę zarówno modelu pytanie-odpowiedź, jak i komunikacji opartej na zdarzeniach. To jest praktyczne w migracji sprzedaży internetowej, bo nie każdy krok zamówienia ma ten sam charakter. Autoryzacja płatności może wymagać odpowiedzi. Wysłanie wiadomości, aktualizacja bazy klientów albo wygenerowanie PDF mogą być zdarzeniami.
NestJS daje spójny model modułów, kontrolerów, dostawców, walidacji, strażników, przechwytywaczy i testów. Dzięki temu usługa zamówień może być mała, ale nie chaotyczna. Może udostępniać punkt wejścia dla finalizacji zamówienia, odbierać zdarzenia z monolitu, publikować informację o opłaconym zamówieniu, trzymać własną bazę i mieć osobny test działania, dzienniki pracy oraz śledzenie przepływu.
W GMI często łączymy NestJS z PostgreSQL, Redis, RabbitMQ albo Kafka, zależnie od potrzeb. RabbitMQ jest dobry dla klasycznych kolejek pracy i potwierdzeń. Redis bywa wystarczający dla prostszych kolejek i pamięci podręcznej. Kafka ma sens, gdy strumień zdarzeń jest produktem samym w sobie: wielu odbiorców, odtwarzanie zdarzeń, audyt i wysoki wolumen.
Strangler Fig: nie przepisywać, tylko przejmować ruch kawałek po kawałku
Microsoft opisuje Strangler Fig jako wzorzec modernizacji, w którym nowy system stopniowo przejmuje żądania dla wybranego obszaru, a system zastany nadal obsługuje resztę. To pasuje do sprzedaży internetowej, bo przepisywanie finalizacji zamówienia metodą "wszystko naraz" jest zbyt ryzykowne: jeden błąd w płatności, stanach albo podatkach może zatrzymać sprzedaż.
Najbezpieczniejszy wariant zaczyna się od mapy obszarów i warstwy tłumaczącej dane między starym a nowym systemem. Stary monolit nadal przyjmuje większość ruchu, ale nowa usługa zamówień zaczyna obsługiwać wąski przypadek: na przykład zamówienia online dla jednego kraju, jednej metody płatności albo jednego kanału sprzedaży firmowej. Dopiero po porównaniu danych, dzienników pracy, płatności i reklamacji zakres rośnie.
Ważne jest, żeby plan powrotu był realny. Jeżeli nowa usługa zamówień zawiedzie, warstwa kierowania ruchu powinna pozwolić wrócić do starej ścieżki dla nierozpoczętych zamówień. Dla rozpoczętych zamówień potrzebujesz kluczy bezpiecznego ponawiania, korelacji zdarzeń i jasnego statusu: przyjęte, opłacone, oczekuje na system finansowo-magazynowy, błąd połączenia między systemami, anulowane.
Architektura referencyjna dla wydzielonej usługi zamówień
Praktyczny model wygląda tak: warstwa użytkownika Next.js albo React Native wysyła finalizację zamówienia do bramy połączeń lub zaplecza przygotowanego pod konkretny kanał. Nowa usługa zamówień w NestJS sprawdza koszyk, zapisuje zamiar złożenia zamówienia w PostgreSQL i publikuje zdarzenia. Broker przekazuje prace poboczne: faktura, wiadomość do klienta, aktualizacja bazy klientów, synchronizacja z systemem finansowo-magazynowym, powiadomienie w aplikacji, raport operacyjny.
Monolit nie znika pierwszego dnia. Nadal może trzymać katalog, konta klientów albo część panelu administracyjnego. Różnica polega na tym, że krytyczna ścieżka "przyjmij zamówienie i nie zgub pieniędzy" ma własny model danych, własne testy, własny wgląd w działanie i własną skalowalność.
Najważniejsza zasada brzmi: działania poboczne nie mogą blokować przyjęcia zamówienia, chyba że są częścią decyzji biznesowej. Płatność, rezerwacja stanów i sprawdzenie ceny mogą być krytyczne. PDF, wiadomość do klienta, baza klientów i wiele operacji systemu finansowo-magazynowego zwykle mogą działać w tle, z ponowieniami, kolejką błędów i powiadomieniem.
Testy, obserwacja działania i warunki produkcyjne
Mikroserwisy bez obserwacji całej ścieżki są gorsze niż monolit, bo problem znika z jednego śladu błędu i rozlewa się po sieci. Minimalny standard to korelacja żądań, ustrukturyzowane dzienniki pracy, metryki kolejki, czas przetwarzania zdarzeń, liczba ponowień, kolejka błędów, pulpit finalizacji zamówienia i powiadomienia biznesowe: spadek konwersji, wzrost błędów płatności, opóźnione zamówienia do systemu finansowo-magazynowego.
Testy muszą pokrywać nie tylko funkcje, ale umowy między systemami. Finalizacja zamówienia powinna mieć testy bezpiecznego ponawiania, podwójnego kliknięcia, przekroczenia czasu płatności, wolnego systemu finansowo-magazynowego, błędu generowania dokumentu i ponownego przetworzenia zdarzenia. Testy prowadzone od strony odbiorców danych są często bardziej użyteczne niż gigantyczne testy całej ścieżki, które padają losowo i niczego nie wyjaśniają.
Podczas warsztatu biznesowo-technicznego ustalamy też odpowiedzialność za utrzymanie: kto reaguje na powiadomienie, kto może ręcznie naprawić zamówienie, kiedy powtarzamy zdarzenie, kiedy anulujemy, a kiedy eskalujemy do finansów lub magazynu. Bez tych decyzji architektura wygląda dobrze na diagramie, ale nie pomaga w poniedziałek o 8:30.
Koszt i zakres: co realnie kupujesz
Wydzielenie jednego krytycznego obszaru sprzedaży internetowej do NestJS zwykle mieści się w szerokim przedziale 160 000-300 000 PLN, ale sama liczba bez wcześniejszego rozpoznania zakresu jest mało wartościowa. Koszt zależy od jakości monolitu, liczby połączeń z innymi systemami, wymagań raportowych, wolumenu zamówień, danych historycznych, poziomu testów i tego, czy system finansowo-magazynowy pozwala na bezpieczną synchronizację.
Najtańszy sensowny zakres to często: mapa obszarów, usługa zamówień, własna baza, warstwa tłumacząca dane z monolitu, broker, podstawowe procesy robocze, pulpit błędów i scenariusze regresji finalizacji zamówienia. Droższe zakresy obejmują wiele krajów, ścieżki akceptacji zamówień firmowych, dzielone wysyłki, kredyt kupiecki, pełny zapis zdarzeń jako źródło prawdy, zaawansowane odtwarzanie zdarzeń i migrację historycznych zamówień.
GMI nie powinno obiecywać stałej ceny przed rozpoznaniem. Obiecujemy szybką konsultację i wstępną estymację w 48h, a stałą cenę dopiero po mapowaniu procesu, połączeń między systemami i danych, kiedy znamy rzeczywiste ryzyka. To szczególnie ważne przy monolitach, bo najdroższe niespodzianki zwykle żyją w starych połączeniach, ręcznych wyjątkach i danych, których nikt nie dokumentował.
Lista kontrolna przed podziałem monolitu
Poniższa lista jest dobrym materiałem na spotkanie dyrektora technologii, sprzedaży internetowej, finansów i operacji. Jeżeli większość odpowiedzi jest nieznana, nie zaczynaj od kodowania mikroserwisu. Zacznij od mapy procesu zamówienia, ryzyk w połączeniach między systemami i pomiarów obecnego systemu.
- Który krok finalizacji zamówienia najczęściej generuje błędy albo opóźnienia?
- Które połączenia z systemami muszą działać natychmiast, a które mogą działać przez zdarzenia?
- Czy mamy klucze bezpiecznego ponawiania dla płatności i zamówień?
- Czy potrafimy porównać wynik starej i nowej ścieżki na tych samych danych?
- Jak wygląda plan powrotu dla nowych ścieżek zakupu i dla zamówień w toku?
- Kto operacyjnie obsługuje kolejkę błędów i ręczne korekty?
- Jakie metryki biznesowe pokażą, że wydzielenie działa: konwersja, skuteczność płatności, opóźnienie zamówienia, opóźnienie synchronizacji z systemem finansowo-magazynowym?
Jak GMI prowadzi taki projekt
Zaczynamy od rozpoznania biznesu, procesu i technologii: mapujemy proces zamówienia, połączenia z systemami, dane, wyjątki operacyjne i ryzyka produkcyjne. Potem proponujemy najwęższy wycinek, który usuwa realny problem: na przykład PDF i system finansowo-magazynowy poza finalizacją zamówienia, osobną usługę zamówień albo najpierw modularny monolit z kolejką działań pobocznych.
Technicznie najczęściej pracujemy w TypeScript: NestJS dla zaplecza, PostgreSQL dla danych transakcyjnych, Redis, RabbitMQ albo Kafka dla kolejek, Next.js lub React Native dla warstw użytkownika, a przy sprzedaży internetowej także MedusaJS tam, gdzie oddzielony rdzeń sprzedaży ma sens. Ale technologia jest wynikiem decyzji o obszarach biznesowych, nie punktem startu.
Biznesowo projekt musi dać klientowi kontrolę: własność kodu źródłowego, brak uzależnienia od dostawcy, stałą cenę po rozpoznaniu zakresu, scenariusze testowe i czytelny model utrzymania. Mikroserwis zamówień jest udany dopiero wtedy, gdy nie tylko działa na pokazie, ale zmniejsza strach przed Black Friday, połączeniem z systemem finansowo-magazynowym i kolejnym wydaniem finalizacji zamówienia.
Źródła i dalsza lektura
Przegląd mikroserwisów NestJS: https://docs.nestjs.com/microservices/basics
Transport RabbitMQ w NestJS: https://docs.nestjs.com/microservices/rabbitmq
Martin Fowler, Monolith First: https://martinfowler.com/bliki/MonolithFirst.html
Microsoft Azure Architecture Center, Strangler Fig Pattern: https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig
From Monolith to Microservices: klasyfikacja podejść refaktoryzacyjnych: https://arxiv.org/abs/1807.10059
From Monolith to Microservices: porównanie metod dekompozycji: https://arxiv.org/abs/2601.23141
Przewodnik GMI po architekturze zdarzeniowej w sprzedaży internetowej z Redis, RabbitMQ i SQS: /blog/event-driven-commerce-redis-rabbitmq-sqs
Przewodnik GMI po NestJS, Prisma i PostgreSQL w dużej skali: /blog/nestjs-prisma-postgresql-at-scale
Najczęstsze pytania
- Kiedy sprzedaż internetowa powinna podzielić monolit na mikroserwisy?
- Wtedy, gdy konkretny obszar ma inne wymagania niż reszta aplikacji: finalizacja zamówienia pada przez działania poboczne, obsługa zamówień wymaga osobnego skalowania, połączenia z systemem finansowo-magazynowym blokują sprzedaż albo ryzyko wydania zatrzymuje zespół. Nie warto dzielić tylko dlatego, że kod monolitu jest nieładny.
- Dlaczego najczęściej zaczyna się od obsługi zamówień?
- Bo zamówienia dotykają przychodu, płatności, stanów magazynowych, faktur, wiadomości do klientów, systemu finansowo-magazynowego i obsługi klienta. Jeśli ten przepływ jest wolny lub kruchy, firma widzi koszt od razu: utracone płatności, ręczne poprawki, opóźnione wysyłki i strach przed wydaniem zmian w finalizacji zamówienia.
- Czy NestJS jest dobrym wyborem do mikroserwisów sprzedażowych?
- Tak, jeżeli zespół pracuje w TypeScript i potrzebuje uporządkowanego zaplecza z modułami, testami, walidacją i obsługą komunikacji między usługami. NestJS nie rozwiązuje sam granic biznesowych, ale daje stabilny szkielet dla usługi zamówień, procesów roboczych i połączeń z innymi systemami.
- Ile kosztuje wydzielenie usługi zamówień do NestJS?
- Typowy zakres dla jednego krytycznego obszaru sprzedaży internetowej to około 160 000-300 000 PLN, ale stała cena ma sens dopiero po rozpoznaniu procesu, połączeń między systemami i danych. Na koszt wpływają połączenia z systemem finansowo-magazynowym, bazą produktów i magazynem, jakość monolitu, wolumen zamówień, migracja danych, testy i poziom obserwacji działania.
- Czy mikroserwisy oznaczają uzależnienie od dostawcy chmury?
- Nie muszą. NestJS w kontenerach, PostgreSQL, RabbitMQ/Redis/Kafka i standardowe sposoby komunikacji można zaprojektować przenośnie. Uzależnienie od dostawcy pojawia się wtedy, gdy logika biznesowa zależy od zamkniętych usług bez warstwy pośredniej i planu wyjścia. W GMI po opłaconych etapach klient otrzymuje prawa do kodu.
- Czy lepiej przepisać cały monolit od razu?
- Zwykle nie. Bezpieczniejszy jest Strangler Fig: nowy system przejmuje jeden wybrany przepływ, stary system obsługuje resztę, a zespół porównuje dane i ma plan powrotu. Przepisanie finalizacji zamówienia metodą "wszystko naraz" jest ryzykowne, bo jeden błąd może zatrzymać sprzedaż.
Treść zaktualizowano: 11 lipca 2026