How to queue OpenAI requests when too many users hit the workflow at once?

If too many users hit your n8n workflow at once and all of them call OpenAI, the safest production‑ready pattern is to queue the requests instead of sending them immediately. In n8n you normally do this by placing incoming items into a database (or Redis) and then processing them with a scheduled or polling workflow that sends requests to OpenAI at a controlled rate. This keeps you inside OpenAI rate limits and prevents n8n executions from piling up and crashing your server.

 

The Practical Solution

 

The stable, production-proven way is:

• Workflow A (Inbound): receives user requests (Webhook Trigger or other Trigger), validates input, and writes the job into a database table or Redis queue. It returns immediately to the user so it doesn’t get stuck.
• Workflow B (Worker/Processor): runs on a Cron or a Pooled Trigger, pulls a limited number of queued jobs, calls the OpenAI node with safe concurrency limits, and stores results back in the database.
• Workflow C (Optional Callback): notifies users (email/webhook) once their job has been processed.

This is how you create an actual queue in n8n. n8n does not have a built‑in queue node, so the queue is simply a database table acting as a buffer.

 

Why This Works

 

• Your Webhook workflow stays fast. It doesn’t wait for OpenAI, so it never times out.
• You control concurrency by choosing how many items Workflow B fetches each run.
• You respect rate limits because you can throttle the OpenAI node or process fewer items per run.
• You avoid n8n execution overflow, where thousands of parallel executions slow the system or get killed.

 

Detailed Step‑by‑Step

 

Here is the real-world pattern people use:

• Create a table in your database (Postgres example): job_id, status, payload, created_at, result.
• Workflow A – Webhook Trigger workflow:
  • Receives POST /generate
  • Writes JSON body to the DB with status='pending'
  • Returns {"queued": true, "jobId": "..."} to the user immediately
• Workflow B – Cron Worker:
  • Runs every few seconds
  • SELECTs limited pending jobs (e.g., LIMIT 3)
  • Calls OpenAI node
  • Updates job record with status='done' and saves OpenAI output

 

Example Query Nodes

 

Workflow A — inserting a job:

INSERT INTO queue_jobs (status, payload, created_at)
VALUES ('pending', {{$json}}, NOW())
RETURNING job_id;

 

Workflow B — selecting jobs to process:

SELECT job_id, payload
FROM queue_jobs
WHERE status = 'pending'
ORDER BY created_at ASC
LIMIT 3;

 

Workflow B — updating after OpenAI response:

UPDATE queue_jobs
SET status = 'done',
    result = {{$json["openai_response"]}},
    completed_at = NOW()
WHERE job_id = {{$json["job_id"]}};

 

Optional Rate Limit Protection

 

• Use the Wait node between batches.
• Use the Split In Batches node to process smaller chunks.
• Use n8n’s built-in retry on failed nodes to handle 429 (Too Many Requests) responses.

 

Important Reality Check

 

If you simply put a Wait node or a Queue node inside the same webhook workflow, it will not solve the problem. Webhooks must return quickly, and n8n will still create one full execution per user load. In high-traffic cases, that collapses your server.

The safe pattern is always: Webhooks enqueue → Worker processes → Stores results.

 

Summary

 

The production-safe way to queue OpenAI requests in n8n is to offload all incoming user requests into a database table (acting as a queue) and process them using a separate Cron-driven workflow that handles a controlled number of jobs at a time. This prevents user spikes from overloading OpenAI or your n8n instance and keeps everything stable under heavy load.