Node-RED flow latency limits under concurrent HTTP requests

Direct Answer

Node-RED does not document—or implement—any runtime-level concurrency limits, queue depth, admission control, or backpressure policy for flows. The core runtime is a thin orchestration layer over Node.js's single-threaded event loop. When multiple HTTP endpoints fire at the same time, any synchronous, CPU-bound work in one flow (typically a Function node) blocks the entire process, delaying every other in-flight request. This cross-request latency is an expected consequence of the event-loop model, not a defect in a particular node or the runtime itself.

There are no supported configuration settings or architectural boundaries within Node-RED that isolate blocking work without changing the code or the deployment topology. Isolation requires moving the blocking work out of the Node-RED process—into an external service, a worker thread, or a separate Node-RED instance—or rewriting the offending node logic to be non-blocking.

Likely Explanation vs. Confirmed Behavior

The distinction that matters is between documented runtime guarantees and emergent platform behavior:

• Confirmed: The core runtime provides no global request queue or concurrency governor. Backpressure exists only at the Node.js stream level, not at the flow-message level.
• Likely explanation: If latency appears only when two or more endpoints fire together, the most probable cause is synchronous execution in one path starving the event loop. This is architectural, not a bug in the HTTP In node or the contrib node performing the work.
• Out of scope: Node-RED does not claim to bound saturation. That responsibility is delegated to individual node implementations and the surrounding infrastructure (reverse proxies, process managers, external workers).

Confirming the Diagnosis

You can verify the event-loop hypothesis with a minimal, scoped experiment:

1. Deploy a flow with an HTTP In node wired to a Function node containing a synchronous busy-wait (for example, a while loop that runs for roughly one second).
2. Send two simultaneous requests to that endpoint. The second response should be delayed by approximately the duration of the first request's synchronous block.
3. Replace the synchronous loop with an asynchronous delay—such as a Promise resolved via setImmediate or setTimeout—and repeat the test. The second request should return without waiting for the first.

If the latency disappears when the blocking work is made asynchronous, the issue is confirmed as event-loop starvation rather than a node-level queueing defect.

Isolation Boundaries

Because the runtime offers no built-in isolation, the supported boundaries are architectural:

• Async rewrite: Ensure Function nodes never perform synchronous CPU-heavy work. Use async/await for I/O, but remember that this prevents loop blocking; it does not cap concurrent operations, which can still exhaust memory.
• External offload: Move heavy computation to a separate microservice, queue, or worker process. Node-RED orchestrates; it does not compute.
• Process separation: Run distinct workloads in separate Node-RED instances behind a reverse proxy. The editor UI shares the same process as flows, so a blocking flow also degrades editor responsiveness.

One Diagnostic Detail That Matters

Is the latency accompanied by sustained high CPU on the Node-RED process, or does CPU stay low while requests wait? If CPU is high, the fix is removing synchronous work from the event loop. If CPU is low, the bottleneck is likely downstream I/O or connection-pool saturation, which changes the recommendation from code refactoring to tuning external dependencies.