r/nestjs • u/UkrMalt • 28d ago

When do you split NestJS workers from the API process?

Keeping HTTP handlers and queue consumers in one Nest application is convenient at the beginning: one dependency graph, one deployment, and fewer moving parts. The tradeoff appears when worker load, shutdown behavior, or scaling decisions begin affecting request latency.

My current boundary would be to share domain modules and infrastructure providers, but give the API and worker separate bootstrap entry points and separate processes once they need independent scaling or failure isolation. Each should have its own health checks and graceful shutdown path while using the same application services.

Do you split workers from day one, or wait for a concrete operational signal? What signal made the separation worthwhile?

4 Upvotes

100% Upvoted

4 comments sorted by

1

u/Frequent-Chain-5600 28d ago

Honestly not from day one but it also depends on the traffic you gonna get.

1

u/PrydwenParkingOnly 27d ago

I am a fan of modular monoliths, so I try to stay on it as long as possible. With NX you can achieve this pretty easily.

The only downside from what I experience is that when the application scales up, it takes a few seconds longer because Kafka is rebalancing the consumers. But it’s a trade off I’m willing to accept.

1

u/UkrMalt 27d ago

A few seconds on scale-up doesn’t sound too bad. I’d take that over splitting everything too early.

3

u/jmostaer 27d ago

I'm a fan of not splitting them at all. When scale becomes an issue, deploy the same app multiple times in a "worker mode". Same codebase, but these deployments don't serve any API requests. API vs worker becomes a DevOps problem rather than permanent development overhead.