Redis + BullMQ for AI Workloads: Retries Are Not Enough — You Also Need Idempotency and Ordering

Description and use

The article explains how using BullMQ for AI processing in a support system leads to race conditions and duplication because retries do not guarantee idempotency or ordering.

Problem

A message can be persisted and queued for AI analysis before the HTTP response is sent, leading to race conditions, duplicate processing, and stale or overwritten results because BullMQ jobs are retried without idempotency or ordering guarantees.

Outcome

The article identifies that retries alone do not guarantee correct AI processing. Without idempotency and per-ticket ordering, jobs can produce inconsistent ticket data and duplicate AIInteraction records.

Workflow

• Create message in database
• Update ticket timestamp
• Publish BullMQ job with ticketId and messageId
• Return HTTP 201 to client
• Worker picks job, loads all ticket messages sorted by createdAt
• Generate ticket summary via OpenAI (or Gemini fallback)
• Generate sentiment via OpenAI
• Detect priority via OpenAI
• Update ticket with aiSummary, sentiment, priority
• Insert AIInteraction record with prompt, response, tokensUsed

Evidence

The request waits for database writes and queue publication, then returns without waiting for the AI results.

Source

The worker may start before HTTP 201 is sent; the diagram shows two execution paths, not a guarantee that background processing begins after the response.

Source

Five jobs can run concurrently within this worker instance, including jobs for the same ticket.

Source