Queues and concurrency
Route tasks and limit how many can run at once.
A Runlane queue gives tasks a route and an execution policy. Producers, workers, maintenance, and transport runtimes must register the same definition.
With a polling lane, workers filter stored work by queue. With SQS, the lane binds that queue to a provider URL. A similar SQS name cannot replace the shared Runlane definition. Each run stores its logical queue name.
Two settings control different limits
| Setting | What it limits | Where it applies |
|---|---|---|
Worker concurrency | Attempts running in one process | One worker process |
Queue concurrencyLimit | Capacity shared by all workers | Storage, across the environment |
Use worker concurrency to tune local fan-out. Use queue concurrency when several processes must respect the same limit.
Partition capacity with a key
Without a concurrency key, one bounded queue has one capacity partition per environment. A task concurrencyKey creates a separate partition for each resource, such as an account.
For example, a queue limit of 2 with the account id as the key allows two attempts per account. Work for different accounts can move independently.
Queued work can briefly reserve capacity before execution. Active work holds capacity through its lease. If dispatch or a worker disappears, expiry makes that capacity available again.
Ordering is separate
Provider ordering and Runlane concurrency solve different problems. FIFO delivery can order messages within its provider partition. Storage still decides whether a run can execute and whether its Runlane capacity partition is full.
Follow limit concurrency to configure both controls. Use choose a lane to pick the delivery setup.