NestJS order microservices: when to split the monolith

An order microservice is a separate app (e.g. NestJS) that owns the order lifecycle and talks to other services via APIs or events.
Warning signals
Multi-vendor carts, per-seller settlements or split checkout grow transactional complexity fast.
When every cart change forces a full regression sweep, it is time to isolate the order domain.
PostgreSQL as source of truth
We keep orders, lines and payments in PostgreSQL with ACID transactions where race conditions are unacceptable.
For reserve-then-pay flows we use explicit locking or optimistic versioning with retries.
Queues and eventual consistency
We emit ERP, warehouse and carrier updates as events with DLQs and “stuck” metrics.
We monitor processing SLA, if the queue grows linearly with traffic, we scale consumers before UX collapses.
Frequently asked questions
- Do we always need Kubernetes?
- No. we start simpler until horizontal scale and observability become the bottleneck.
- How do you test distributed orders?
- API contracts, integration tests with containers and queue chaos scenarios, before the first big drop.
- Where does Medusa fit?
- Medusa can own catalogue and checkout; a NestJS order-splitting engine appears when logic exceeds the default model.
Content updated: March 17, 2026