Rate limit per job-type

[manast]

In some scenarios it is useful to be able to limit jobs by job type instead of by queue. We could easily accomplish this by having several rate limiter keys per queue, depending on the job type.

[csingh]

I like this idea, and would personally find it very useful!

What about taking this a step further and allowing for a global rate limiter that could work across different queues? Would this be significantly more work?

Here is some motivation: We are building a system that utilizes some API. Say we have different queues that handle different job types which hit the API, but the API has a usage limit. How can we enforce a rate limit across these queues?

[moltar]

I have a similar use-case, but even more fine-grained. The API I am using has limits per-user. Our systems manages multiple user tokens to fetch data from the API.

I'd be nice to be able to handle this kind of scenario gracefully, although I don't know the best way.

[nitzanav]

+1

[shc023]

The only way I can think of doing this right now is to have only a single Queue per rate-limited API, and then have something like job.data.type that then actually determines what processing function to run.

Something like:

const fooAPIQueue = new Queue('any foo API actions', ...);

fooAPIQueue.process(function(job) {
  switch(job.data.type): {
    case doThingA:
      // does the actual processing you want for the do-thing-A "job"
    case doThingB:
      // does the actual processing you want for the do-thing-B "job"
  }
});

But yes, +1 to allowing rate-limiting across queues, so that we can write them one for each task as intended.