Node-RED flow latency limits under concurrent HTTP requests

Node-RED executes flows on Node.js's single-threaded event loop, so concurrent HTTP requests or timer-driven messages share one execution context. When one flow performs synchronous work, every other in-flight request can be delayed even if the flows are logically unrelated. The runtime does not appear to define a global concurrency policy, queue depth, or admission control; those concerns are left to individual nodes or the deployment environment.

The goal is to determine whether this cross-request latency is a documented behavioral limit of the core runtime, a node-specific implementation concern, or an expected consequence of the event-loop model. It is unclear which parts of the platform are intended to bound saturation and which are explicitly out of scope. Asynchronous coding in Function nodes is a known mitigation, but the boundary between supported runtime behavior and node responsibility remains ambiguous.

Does Node-RED document any runtime-level concurrency, queueing, or backpressure limits for flows? Is latency that appears only when multiple endpoints fire simultaneously considered expected event-loop behavior or a defect in a particular node? Are there supported configuration or architectural boundaries for isolating blocking work without changing each node individually?