Introduction

async and await make asynchronous JavaScript easier to read, but they do not make slow control flow disappear. When code starts to scale badly, the problem is usually not the syntax itself. It is that a nested structure is accidentally forcing independent operations to run one after another.

Why Nested await Often Becomes Serial Work

An await pauses the current async function until one promise settles. That is fine when each step truly depends on the previous result, but it becomes expensive when the code nests loops or helper calls that could have run in parallel.

Consider this pattern:

1async function loadOrders(userIds) {
2  const result = [];
3
4  for (const userId of userIds) {
5    const user = await fetchUser(userId);
6    const orders = await fetchOrders(user.id);
7    result.push({ user, orders });
8  }
9
10  return result;
11}

This looks clean, but it is fully serial. If there are 100 users, the next user does not even start loading until the previous user's orders finish.

If the operations are independent, build the promises first and await them together:

1async function loadOrders(userIds) {
2  const users = await Promise.all(userIds.map(fetchUser));
3
4  const combined = await Promise.all(
5    users.map(async (user) => {
6      const orders = await fetchOrders(user.id);
7      return { user, orders };
8    })
9  );
10
11  return combined;
12}

This version still uses await, but it exposes concurrency where it is safe.

Parallelism, Concurrency, and Backpressure

The fix is not always Promise.all everywhere. Launching thousands of requests at once can overwhelm a database, remote API, or the Node.js process itself. Scaling async code means balancing concurrency instead of turning every loop into a firehose.

A simple concurrency limiter is often better:

1async function mapWithLimit(items, limit, worker) {
2  const results = [];
3  let index = 0;
4
5  async function runOne() {
6    while (index < items.length) {
7      const current = index;
8      index += 1;
9      results[current] = await worker(items[current]);
10    }
11  }
12
13  await Promise.all(Array.from({ length: limit }, runOne));
14  return results;
15}
16
17async function loadOrders(userIds) {
18  return mapWithLimit(userIds, 5, async (userId) => {
19    const user = await fetchUser(userId);
20    const orders = await fetchOrders(user.id);
21    return { user, orders };
22  });
23}

This pattern keeps only a controlled number of operations in flight, which is often what scaling actually requires.

Nested await and Hidden N+1 Problems

Nested async code often hides an N+1 query pattern. For example, fetching a list of users and then calling another service once per user can be correct functionally and still perform poorly.

If the downstream system supports batch calls, that is often better than clever promise choreography.

1async function loadOrders(userIds) {
2  const users = await fetchUsersByIds(userIds);
3  const ordersByUserId = await fetchOrdersForUsers(userIds);
4
5  return users.map((user) => ({
6    user,
7    orders: ordersByUserId[user.id] ?? []
8  }));
9}

This scales better because the architecture changed, not because the await placement changed.

Error Handling in Larger Async Flows

Nested code also becomes harder to reason about when failures happen. A single rejected promise inside deeply nested async loops can stop the whole operation or leave partial data behind.

When you need partial success, Promise.allSettled can be more appropriate than Promise.all.

1async function loadProfiles(userIds) {
2  const settled = await Promise.allSettled(userIds.map(fetchUser));
3
4  return settled.map((entry, index) => {
5    if (entry.status === "fulfilled") {
6      return { userId: userIds[index], user: entry.value, error: null };
7    }
8
9    return { userId: userIds[index], user: null, error: entry.reason };
10  });
11}

Scaling is not only about speed. It is also about failure isolation and predictability.

When Serial await Is Actually Correct

Not all nested awaits are bugs. If step two depends on data from step one, serial execution is the right behavior. For example, authentication before fetching account data is inherently ordered.

The real question is simple: does this await enforce a dependency, or is it just sitting inside the nearest loop because that was the easiest code to write?

Common Pitfalls

A common mistake is assuming await automatically makes code concurrent. It does not. It only pauses until one promise completes.

Another issue is replacing every nested loop with Promise.all and accidentally creating unbounded concurrency. That can shift the bottleneck from slow code to overloaded infrastructure.

Developers also sometimes optimize promise structure while ignoring the real problem, such as repeated round trips that should be replaced with one batch API call.

Finally, error handling gets messy when nested async code grows organically. Decide early whether one failure should stop everything or whether partial results are acceptable.

Summary

• Nested await often scales poorly because it serializes work.
• Use Promise.all when tasks are independent and safe to run together.
• Add concurrency limits when the downstream system cannot handle unlimited parallelism.
• Look for N+1 patterns before blaming the async syntax itself.
• Treat failure behavior as part of scalability, not just runtime speed.