Skip to main content

Specify a smaller concurrencyKey concurrency limit

Feature Request

This would allow for being able to have a concurrency limit on the entire queue, lets say 10, but each concurrency key only gets lets say 1 at a time. So the queue would never been executing more than 10 at once, and each concurrency key would only ever execute 1 in parallel.

See this real world use-case: https://x.com/euboid/status/1929470623191101613

Posted by Eric Allam ·
Status: Completed2 comments

Comments2

  • mattaitken

    Team•

    Oct 8

    You can read the full details on multiple concurrency limits and setting perKey and total here: https://trigger.dev/changelog/multiple-concurrency-limits

  • Iss Haddad

    Team•

    Jul 30

    Relaying a use case for this, plus a refinement worth folding in.

    Use case: A third-party API with a hard account-wide concurrency cap of 20, where each run corresponds to a single API call and work is spread across many tenants. With concurrencyKey: customerId and concurrencyLimit: 10, 10 active tenants can run 100 requests concurrently, so the external cap can't be respected. Dropping the key gives a global ceiling, but then one tenant's 1,200 queued runs dequeue by age and can starve everyone else.

    Refinement: A fixed per-key limit respects the cap but underutilizes it. For example, with 5 active tenants and a limit of 1 each, only 5 of 20 available slots are used, and a single active tenant is limited to 1 instead of being able to use all 20. It would be better if each key's allowance were derived from how many keys are active at that moment, while still allowing unused capacity to burst to active keys. In other words, the per-key share should be computed dynamically rather than configured statically.