Library · Reliability

Background jobs & queues.

By Mokshify Engineering · Reviewed by the team · Updated 17 Jul 2026 · 6 min read

The problem

Some work does not belong in the request path: sending email, generating reports, calling slow third parties, running AI inference. Done inline, they make users wait and turn one provider’s bad day into your outage. The answer is a queue - and a set of disciplines that make asynchronous work trustworthy instead of merely invisible.

The architecture

The API validates, enqueues and answers immediately with something honest (“accepted, here is where to check”). Workers pull jobs, do the slow thing, and record status the client can read. Between those two sentences live all the disciplines that matter.

The disciplines

Redis queues vs a real broker

Redis-backed queues (our default): one service you already run, ordering and delivery guarantees good enough for product workloads, minimal ops. Advantages: simplicity, cost, familiarity. Disadvantages: weaker delivery semantics than a purpose-built broker; replay and fan-out are manual; very high throughput gets uncomfortable.

A dedicated broker (RabbitMQ, Kafka) earns its operational weight when you need durable event streams, replay, many consumers per event, or six-figure messages per minute. Adopting Kafka for a startup’s email queue is how boring-technology budgets get spent on plumbing - we will tell you when you actually need it.

Technology selection

Redis (see the ADR) with worker processes in the same language as the service that owns the domain - Node.js or Python. AI inference jobs follow this exact shape: enqueue, infer, evaluate, record - see the RAG pipeline diagram.


Related: Caching strategy · AI Product Development · Quality assurance · Engineering decisions