Execution Models

The Rust core owns scheduling — it claims due jobs from storage and dispatches them. Execution happens back in your Node process: the core hands each job to a JavaScript callback and awaits the returned promise. Handlers run on the single Node event loop, just like the rest of your app.

Concurrency

Jobs run concurrently, not one at a time. Each dispatched job is an independent async invocation, so while one handler awaits I/O another can run. In-flight work is bounded by:

• channelCapacity (default 128) — the worker's in-flight dispatch buffer.
• per-task maxConcurrent and queue concurrency — explicit caps.
• per-task / per-queue rate limits.

batchSize (default 1) controls how many jobs the scheduler claims per poll — raise it to amortize polling under high throughput.

queue.runWorker({ queues: ["default"], channelCapacity: 256, batchSize: 16 });

There is no GIL, thread-pool sizing, or prefork choice to make — concurrency is ordinary event-loop async.

CPU-bound work

Because handlers share the event loop, a long synchronous computation blocks every in-flight job. For CPU-heavy tasks:

• Offload to a worker_threads pool or a native addon, and await it.
• Or run several worker processes against the same storage — the core hands each job to exactly one of them.

Scaling out

Horizontal scaling is just more worker processes (or machines) pointed at shared Postgres or Redis storage. The core claims each job for a single worker, so adding workers adds throughput without duplicate execution — see guarantees.