Async Doesn’t Mean Infinite Concurrency in Node.js

Node.js makes concurrency easy with async/await and Promises.

But there’s a dangerous misconception:

If it’s async, you can run unlimited operations safely.

You can’t.

Unbounded concurrency can silently degrade your system.

Consider this common pattern:

await Promise.all(events.map(publishEvent));

Looks efficient but if events.length = 10,000, this creates 10,000 concurrent operations.

This can overwhelm:

• Database connection pools


• RabbitMQ / Kafka connections


• Downstream services


• Memory and event loop scheduling

Async removes thread blocking, not resource limits.

What actually happens under load

Each async operation still consumes resources:

• Network sockets


• File descriptors


• Memory


• Connection pool slots


• CPU time for callbacks

Too many concurrent promises can cause:

• Connection pool exhaustion


• Increased latency


• Timeouts


• Cascading failures

Ironically, trying to go faster makes the system slower.

The solution: Bounded concurrency

Process work in controlled parallel batches instead of all at once.

Example: limit concurrency to 10

import pLimit from "p-limit";



const limit = pLimit(10);



await Promise.all(events.map((event) => limit(() => publishEvent(event))));

This ensures:

• Maximum 10 concurrent operations


• Stable resource usage


• Predictable throughput

This pattern is critical for:

• Outbox event publishers


• Message consumers


• Bulk database operations


• API integrations


• Background workers

Concurrency should be intentional, not accidental.

In production systems, bounded concurrency is often faster than unbounded concurrency.

Because stability scales. Chaos doesn’t.