timgit / pg-boss

Queueing jobs in Postgres from Node.js like a boss
MIT License
1.95k stars 153 forks source link

Scaling horizontally #320

Closed ajmnz closed 2 years ago

ajmnz commented 2 years ago

Hey 👋🏼

We are scaling our backend horizontally, but we want only one container to be responsible for calling work since we don't want to hammer the db with each instance adding more and more workers.

After reading #225, it isn't quite clear for us what new PgBoss and boss.start() actually do. In our use case, one instance should be calling all new, start(), work(), schedule() and onComplete(), but then if the other instances only need to be able to send jobs, what should they be calling? Only new or start() too?

Also, if say the containers were going to switch roles and one needs to become the new "queue master", will calling stop() on the previous master allow for new jobs to be sent by the same instance later on?

Thanks in advance!

timgit commented 2 years ago

Hey there :wave: !

You should be calling start() on all instances, which distributes the work of queue maintenance across all of them. This only involves sending the database a few maintenance commands, so it's not a lot of overhead. You can opt out of cron on some of these if you want. stop() will turn off the timers and job fetches for maintenance on an instance, but still allow sending new jobs. This is a bit more risky, since you may lose the instance that was designated as your "queue master".

ajmnz commented 2 years ago

Awesome! We'll have to run some tests with calling stop() and start() on the same instance, but this should never happen unless the "master" container dies unexpectedly. Anyway, seems like stop() was what we needed, and thanks for the cron tip!