Open sourceBackend design, queue lifecycle, worker orchestration
tinyqueue - redis-backed job queue
A small Redis-backed job queue focused on predictable background processing, retry behavior, and worker visibility.
Problem
Most projects need background work before they need a heavy queue platform. The goal was to build a queue that stays understandable while still covering retries, concurrency, and job state tracking.
Architecture
- Redis stores queued jobs, active work, completion state, and retry metadata.
- Workers pull FIFO jobs and process them with configurable concurrency.
- Failed jobs move through exponential backoff before being retried or marked failed.
- A monitoring layer exposes job state so failures are visible during development.
Key decisions
- Kept Redis as the core dependency because it fits queue semantics and is easy to run locally.
- Designed the API around explicit job states instead of hiding lifecycle transitions.
- Made retry behavior predictable with bounded exponential backoff.
Tradeoffs
- Redis keeps the system fast and simple, but durable long-term history still belongs in a database.
- FIFO behavior is easy to reason about, but priority scheduling would need another layer.
What I learned
- Queue design is mostly failure design: retries, stuck jobs, visibility, and idempotency matter more than enqueue speed.
- Small infrastructure libraries need a narrow API surface or they become harder to trust.
Stack
TypeScriptExpress.jsRedisBunJob QueueBackground WorkersFIFOExponential BackoffReal-time Monitoring