If the job has to take decision based on complex logic then it can he handled in the job itself instead of doing it before enqueuing the job. But for simple conditionals, we can check them beforehand to avoid enqueuing of the job and immediately discarding.

I personally think having extra jobs doesn’t cost if all it do is simply return. But having simple conditions inside job too, saves refactor and make code consistent. Plus, lower chances that someone will end up converting simple logic -> hard logic outside job in future.

Yes. But that depends on the job queue architecture and scale of operations. Pushing jobs to a queue involves writing data to a store and later reading it from the worker (Redis + Sidekiq or RabbitMQ + Celery, for example). We can avoid all that IO and persistence by utilising some compute near the job enqueue. That's our trade-off. The idea is to think about bounded and unbounded queues. • Do you just keep pushing to the job queue not thinking of its size and other things? • Or do you moderate the load to the queue by deciding beforehand? No one way is better. For all we know, the domain rules for pushing to a job could be costly and we do want to push them the job.

also depends on the operation itself and usage pattern. If the only 10 out of 1m orgs are going to use slack then enqueuing 1m jobs is not efficient

Yes, that’s true but I feel most of the times infrastructure can be scaled. I was also thinking even if it is simple if/else return — queue size shouldn’t increase that much. Plus having the condition at 10 places, wherever SlackNotify is being called would be weird v/s having it at one place. But yes definitely trade-offs based on what factor anyone is optimising.

Good point Shivam