iii-queue

The iii-queue worker provides asynchronous job processing with retries, configurable concurrency, FIFO ordering, and dead-letter (DLQ) support. It runs in two modes. Topic-based queues are durable pub/sub: register a consumer with a durable:subscriber trigger and produce with iii::durable::publish — every distinct function subscribed to a topic receives a copy of each message (fan-out). Named queues are defined in config (queue_configs) and targeted by enqueuing a function call with TriggerAction.Enqueue — no trigger registration needed, the target function is the consumer.

Three adapters back delivery: builtin (in-process; in_memory or file_based; single-instance; retries + DLQ + FIFO), rabbitmq (durable delivery, retries, and DLQ across instances), and redis (multi-instance topic pub/sub only — it publishes to named queues but does not implement named-queue consumption, retries, or DLQ). Choose builtin for local and single-instance, rabbitmq for multi-instance production.

When to Use

A unit of work should run asynchronously with automatic retries and dead-letter capture on repeated failure.
You need strict ordering within a key (FIFO) — payments, ledger entries, state machines — via a fifo queue with message_group_field.
Durable fan-out where every subscribed consumer must process every event (unlike iii-pubsub, which is fire-and-forget).
You need to inspect or recover stuck work: browse a DLQ and redrive or discard messages.

Boundaries

Not fire-and-forget broadcast — for ephemeral notifications where missed events are fine, use iii-pubsub.
The redis adapter is publish-only for named queues; named-queue consumption, retries, and DLQ require builtin or rabbitmq.
FIFO queues force prefetch=1 (one job at a time) and require message_group_field present and non-null in every payload; they trade throughput for ordering and retry inline (blocking the group until success or DLQ).
This worker carries work items, not key/value or stream state — use iii-state / iii-stream for those.