NestJS i mikroserwisy zamówień: kiedy dzielić monolit?
Mikroserwis zamówień to osobna aplikacja (np. NestJS), która posiada własny model życia zamówienia i komunikuje się z innymi usługami przez API lub zdarzenia.
Sygnały ostrzegawcze
Wdrożenia z wieloma dostawcami w jednym koszyku, rozliczeniami per seller lub split checkoutem szybko rosną w złożoność transakcyjną.
Gdy każda zmiana w „koszyku” wymaga regresji całej aplikacji, czas rozdzielić domenę zamówień.
PostgreSQL jako źródło prawdy
Trzymamy spójny model encji zamówienia, pozycji i płatności z transakcjami ACID tam, gdzie musi być zero race conditions.
Dla wzorców „najpierw rezerwacja, potem płatność” stosujemy jawne blokady lub wersjonowanie optymistyczne z retry.
Kolejki i spójność ostateczna
Powiadomienia do ERP, magazynów i kurierów wysyłamy jako zdarzenia z dead-letter queue i metrykami „stuck”.
Monitorujemy SLA przetwarzania, jeśli kolejka rośnie liniowo z ruchem, skalujemy konsumentów zanim padnie UX.
Najczęstsze pytania
- Czy zawsze potrzebujemy Kubernetes?
- Nie. zaczynamy od prostszego hostingu, dopóki skalowanie horyzontalne i observability nie stają się wąskim gardłem.
- Jak testujecie rozproszone zamówienia?
- Kontrakty API, testy integracyjne z kontenerami i scenariusze chaos na kolejkach, zanim pierwszy duży drop.
- Co z Medusa w tym obrazku?
- Medusa może być warstwą produktów i checkoutu; silnik podziału zamówień bywa osobnym modułem NestJS, gdy logika przekracza standard.
Treść zaktualizowano: 17 marca 2026