Asynq

Asynq is a Go library for queueing tasks and processing them asynchronously with a pool of worker goroutines. It is backed by Redis, using the broker purely as a fast, durable message store rather than requiring a separate queue service, so a Redis instance you likely already run can double as the task backend. A Client enqueues tasks (immediately, scheduled for later, or on a recurring cron-like schedule), and a Server pulls them off one or more priority-weighted queues and dispatches them to a Handler implementation, similar in shape to net/http’s ServeMux.

Beyond basic enqueue/process, Asynq handles the operational edges that hand-rolled queue code usually gets wrong: automatic retries with backoff, recovery of in-flight tasks after a worker crash, task de-duplication via a uniqueness key, per-task timeouts and deadlines, task aggregation for batching related work, and Redis Sentinel support for broker failover. A companion Web UI (Asynqmon) and a asynq CLI tool provide live inspection and control over queues, active tasks, and the retry/archive sets.

What You Get

• Client/Server API for enqueueing tasks and running worker pools with configurable concurrency and weighted or strict queue priorities
• Automatic retries with configurable max-retry counts, plus automatic recovery of tasks left in-flight when a worker crashes
• Task scheduling: process-in/process-at delays and recurring periodic tasks via a cron-style scheduler
• Task de-duplication (unique tasks), per-task timeouts/deadlines, and task aggregation for batching related work together
• A ServeMux-style handler interface with middleware support, modeled on net/http
• Prometheus metrics integration plus a companion Web UI (Asynqmon) and CLI tool for inspecting and remote-controlling queues and tasks

Common Use Cases

• Offloading slow or unreliable work (email delivery, image/video processing, webhooks) out of the request path into background workers
• Scheduling one-off delayed jobs (e.g. send a reminder in 24 hours) or recurring periodic jobs (e.g. nightly reports) without a separate cron daemon
• Building a horizontally scalable worker fleet where multiple server processes pull from shared Redis-backed queues with priority weighting between queue classes
• Guaranteeing at-least-once execution of critical operations with automatic retry and crash recovery instead of hand-rolling that logic per job type

Under The Hood

Architecture A Server composes several independently-running background components — forwarder, processor, syncer, heartbeater, subscriber, recoverer, healthchecker, janitor, and aggregator (server.go) — each responsible for one slice of the task lifecycle (moving scheduled tasks into pending queues, executing handlers, syncing state back to Redis, detecting dead workers, requeuing orphaned tasks, and cleaning up completed/archived sets). All Redis interaction is isolated behind an internal RDB client (internal/rdb) that wraps redis.UniversalClient and performs queue mutations through Lua scripts, so multi-step operations stay atomic even under concurrent workers. Client and Server both depend on a base.Broker interface rather than talking to Redis directly, which is what makes the library’s own test suite able to substitute a fake broker; a breaking change to that interface would ripple through the processor, forwarder, and recoverer simultaneously.

Tech Stack Asynq targets modern Go (module declares go 1.24, CI tests against 1.24.x and 1.25.x) and layers on top of redis/go-redis/v9 as its only external Redis client dependency. robfig/cron/v3 powers periodic task scheduling, golang.org/x/time backs rate limiting in the companion x module, and google.golang.org/protobuf handles internal message serialization. The repository is split into three Go modules — the core library, a tools/ module (the asynq CLI), and an x/ module for extensions like Prometheus metrics export and rate limiting — keeping optional, heavier dependencies out of the core import graph.

Code Quality The project carries extensive test coverage: 27 _test.go files exercise the client, server, processor, aggregator, recoverer, scheduler, and inspector, using google/go-cmp for comparisons, go.uber.org/goleak to catch goroutine leaks, and a dedicated testbroker package to simulate broker behavior deterministically. CI runs the full suite with the Go race detector against a live Redis 7 service container across two Go versions, then uploads coverage to Codecov — this is integration-style testing against a real broker, not just mocks. Errors flow through a dedicated internal/errors package rather than being swallowed, and comment density across core files is comprehensive.

What Makes It Unique Most Go task-queue libraries stop at enqueue-and-process; Asynq additionally ships operationally-focused features usually left to the adopter to build themselves — weighted and strict queue priorities, live queue pausing, task aggregation/batching, Redis Sentinel failover support, and a full Web UI plus CLI for inspecting and remote-controlling queues in production. The base.Broker abstraction and Lua-script-backed atomic operations give it stronger consistency guarantees under concurrent workers than a naive Redis list-based queue would provide.