EffectMQ documentation

EffectMQ is a Redis-backed task queue for Effect applications. Payloads, success values, and handler failures are described with Effect Schema and stay typed from the producer through the worker to the caller waiting for a result.

EffectMQ provides fenced, at-least-once task execution. It handles durable task state, retries, delays, cron materialization, result retention, and lifecycle events. Your application controls handler concurrency and makes external side effects idempotent.

The four parts

EffectMQ separates descriptions from runtime operations:

1. Define a task with Task.make. This pure value owns the payload, success, and failure schemas plus retry and retention policy.
2. Define a queue with TaskQueue.make. This pure value binds a queue name to the task definition.
3. Offer work with TaskQueue.offer. This Effect encodes a payload and persists it through the engine.
4. Work the queue with Worker.run or TaskQueue.complete. These Effects acquire tasks, run the handler, and persist outcomes.

Task and queue definitions can live at module scope. Only offering, processing, waiting, scheduling, and Redis wiring need an Effect runtime.

Start here

• Build your first queue is a complete, runnable lesson with Redis, a producer, and a managed worker.
• Process tasks with managed workers shows how to configure concurrency, lease supervision, and graceful shutdown.
• Understand the delivery model explains what fenced at-least-once execution guarantees and what it cannot guarantee.

Solve a problem

• Retry, delay, and deduplicate work
• Wait for results and consume events
• Schedule recurring tasks
• Make handler side effects idempotent
• Operate Redis for EffectMQ

Look up an API

• Task reference
• TaskQueue reference
• Worker and Scheduler reference
• Redis and runtime reference
• Error reference

Requirements

EffectMQ requires Node.js 22.19 or newer and uses Effect 4 beta. Redis standalone and Redis Sentinel are supported. Redis Cluster is not supported.