Overview
Conveyor has three moving parts: your client enqueues tasks, the server owns them, and your workers process them. A durable broker is the source of truth, and tasks are persisted before they're dispatched, so they survive any crash.
Getting started
The two halves of using Conveyor, a worker that registers a handler per task type and a client that enqueues tasks, have the same shape in every SDK.
Features
Named queues with weights, bounded worker concurrency, retries with configurable backoff, per-task priorities, delayed and scheduled tasks, cron, unique tasks, retention and archival, and a read-only admin and inspection API, all enforced server-side. Your code only writes handlers and enqueues tasks.
Operations
The server coordinates queues, scheduling, and lease recovery across a cluster of conveyord nodes: they rebalance automatically when a node is lost, and no task is dropped. Scale by adding nodes; the broker is the only stateful dependency.
The server pushes tasks to workers the instant work exists and a worker has free capacity, so there's no poll interval to tune and no Redis. Each worker opens one persistent connection, tells the server which queues it serves and how much it can handle, and receives work over that stream. When a worker is saturated it simply stops accepting more, and the extra work waits safely in the broker.