Kiedy podzielić monolit na mikroserwisy (NestJS)?
TL;DR - Szybkie podsumowanie
- Ochrona koszyka: Mikroserwisy odcinają awarie poboczne (e-mail, PDF) od głównej ścieżki zakupu - checkout nie pada razem z modułem faktur.
- Stack GMI: NestJS na Node.js + komunikacja asynchroniczna (event-driven) - odporność na skoki ruchu.
- Zasada 100 000+: Architekturę utrwalamy w produkcji (np. SFD: 100 000+ pobrań, 4.9★, stabilne szczyty typu Black Friday).
- Migracja: DDT (Discovery, Design & Technology) i gwarancja ceny stałej na wydzielenie serwisów - mniejsze ryzyko dla CTO.
Problem: Moduł faktur ubił całą sprzedaż na Black Friday
W szczycie koszyk przestaje działać, sklep zwraca 500. Diagnoza: zewnętrzny generator PDF zwolnił, kolejka w monolicie zapchała RAM i wysadziła cały serwer.
W monolicie (stary Magento, PHP „kombajn”) koszyk, płatności i maile dzielą jeden proces - pada jeden moduł, pada biznes. GMI Software z Gdańska (16+ lat) tną monolit na usługi NestJS tam, gdzie ma to sens.
Monolit vs mikroserwisy - kiedy podział ma biznesowy sens?
Rozproszenie nie może wynikać z mody:
- Monolit: Jeden kod, jedna baza. Zostaw, gdy masz poniżej 100-200 zamówień dziennie i zespół 2-3 osoby - taniej w utrzymaniu, prostsze małe zmiany.
- Mikroserwisy (NestJS): Zamówienia, płatności, magazyn to osobne aplikacje (np. AWS ECS), osobne bazy. Wdrażaj, gdy baza się dławi, integrujesz ciężkie ERP, a awaria poboczna nie może zabić checkoutu.
Opinia GMI: Zwykle zostawiamy frontend i katalog w spokoju i zaczynamy od najwyższego ryzyka - order management: płatności i rezerwacja stanów.
Jak technicznie wydzielamy zamówienia? (stack GMI)
**Event-driven** w praktyce:
- Frontend (Next.js / React Native): Klik „Kupuję i płacę”.
- Serwis zamówień (NestJS): Zapis intencji w PostgreSQL, szybkie zwolnienie UI.
- Broker (Redis / RabbitMQ): Zamiast czekać na księgowość - event w tle, np. „zamówienie #1234 opłacone”.
- Workery: Faktury PDF i push idą osobno; jak PDF pada, kolejka czeka, klient już zapłacił (Stripe itd.), checkout żyje.
Ten sam kierunek stosujemy przy MedusaJS v2 - separacja logiki to baza headless.
Ile kosztuje wydzielenie mikroserwisów z monolitu?
Refaktoryzację budżetujemy etapami:
- Koszt: Wydzielenie krytycznego modułu (koszyk, płatności, ERP) do NestJS - zwykle 160 000-240 000 PLN; duże B2B bywa powyżej 250 000 PLN.
- Czas: Jeden duży moduł stabilnie 3-6 miesięcy zespołu.
Bezpieczeństwo: Przepisywanie lubi rozjeżdżać terminy. GMI Software to jedyny software house w Polsce, który audytuje stary kod w DDT, potem daje gwarancję ceny stałej na konkretny mikroserwis.
Najczęściej zadawane pytania
- Czym jest NestJS i dlaczego GMI Software go używa do mikroserwisów?
- NestJS to framework backendowy na Node.js i TypeScript. Wymusza strukturę modułów i wzorce znane z Angulara - kod jest przewidywalny, łatwy w testach i nadaje się do stabilnych mikroserwisów e-commerce, często obok MedusaJS.
- Po czym poznać, że e-commerce potrzebuje podziału na mikroserwisy?
- Sygnały: awarie poboczne blokują checkout, każda funkcja wymaga pełnej regresji monolitu, serwer nie domyka szczytów (Black Friday) samym dokupieniem RAM.
- Ile kosztuje migracja modułu z monolitu do mikroserwisu w NestJS?
- Wydzielenie silnika zamówień lub promocji to zwykle 160 000-240 000 PLN. Zawsze poprzedzamy DDT, żeby zamrozić zakres i dać gwarancję ceny stałej.
- Czym jest Event-driven architecture w systemach zamówień?
- Usługi publikują zdarzenia do kolejki zamiast synchronicznie czekać na siebie. Magazyn i mailing reagują w swoim tempie - wolny PDF nie paraliżuje sklepu.
- Czy budowa mikroserwisów uzależnia firmę od chmury (vendor lock-in)?
- Nie - kontenery Docker na AWS ECS da się przenieść na GCP, Azure lub metal, bez zmiany logiki. Po opłaceniu etapów przekazujemy pełnię praw do kodu.
Treść zaktualizowano: 31 marca 2026