Understanding Deployment Strategies for `bullmq` and `@effect/workflow`
I'm having trouble understanding the deployment strategies between
My usual use case for bullmq is background processing, database cleanup cron jobs, and sending emails. I'll have an API Node.js process and a separate bullmq worker Node.js process, both usually running via Docker. Where do durable workflows fit in here? It seems like you can run workflows or bullmq in the same process as the API, or even as separate processes on the same server, but depending on usage, it may make more sense to have them on separate servers to not bog down the API server.
Other than CPU/memory usage, what is the determination people use for splitting the workflow management into its own Node.js process or separate server? I've seen some threads about Kubernetes + clusters but I'm not at that scale at all
thanks!
bullmq@effect/workflowMy usual use case for bullmq is background processing, database cleanup cron jobs, and sending emails. I'll have an API Node.js process and a separate bullmq worker Node.js process, both usually running via Docker. Where do durable workflows fit in here? It seems like you can run workflows or bullmq in the same process as the API, or even as separate processes on the same server, but depending on usage, it may make more sense to have them on separate servers to not bog down the API server.
Other than CPU/memory usage, what is the determination people use for splitting the workflow management into its own Node.js process or separate server? I've seen some threads about Kubernetes + clusters but I'm not at that scale at all
thanks!
Similar Threads
Was this page helpful?
