Introduction

Having many async methods in a call chain is not automatically a problem. What matters is whether the asynchronous structure still matches the real workflow clearly, handles errors in one predictable place, and avoids unnecessary serialization.

In other words, the issue is usually not "too many async functions." The issue is poor orchestration, hidden dependencies, or deeply nested control flow that makes timing and failure behavior hard to reason about.

Nested async Calls Are Often Normal

This kind of code is completely reasonable:

1async function loadUser(id) {
2  const response = await fetch(`/api/users/${id}`);
3  return response.json();
4}
5
6async function loadDashboard(id) {
7  const user = await loadUser(id);
8  return {
9    user,
10    message: `Loaded ${user.name}`,
11  };
12}

One async function awaiting another is just composition. The fact that several layers are involved is not itself a design smell.

The design becomes harder to maintain when the nesting introduces:

• duplicated error handling
• unclear sequencing rules
• long chains of single-purpose pass-through functions
• sequential waiting for tasks that could run concurrently

The Real Problem: Accidental Serialization

Many async codebases become slower and more complex because independent operations are awaited one after another instead of being started together.

This version is correct but unnecessarily sequential:

1async function loadPageData() {
2  const user = await fetchUser();
3  const notifications = await fetchNotifications();
4  const settings = await fetchSettings();
5
6  return { user, notifications, settings };
7}

If those requests do not depend on one another, concurrency is clearer and faster:

1async function loadPageData() {
2  const [user, notifications, settings] = await Promise.all([
3    fetchUser(),
4    fetchNotifications(),
5    fetchSettings(),
6  ]);
7
8  return { user, notifications, settings };
9}

Here the important improvement is not fewer async methods. It is better control over execution order.

Deep Nesting Versus Layered Abstraction

A long chain of await calls can still be healthy if each layer owns a real concern:

• API client
• domain service
• application workflow
• controller or UI layer

That layering is useful. It becomes a problem when every layer simply forwards the same data with no real behavior:

1async function stepA(id) {
2  return stepB(id);
3}
4
5async function stepB(id) {
6  return stepC(id);
7}
8
9async function stepC(id) {
10  return fetchUser(id);
11}

These wrappers add stack depth and mental overhead without adding meaning.

Error Handling Is Usually the Stress Test

Async design quality becomes obvious when something fails. If every nested method has its own try and catch block that logs, wraps, or partially swallows errors, tracing failures becomes difficult.

A cleaner pattern is to let lower-level functions throw and handle the error at the boundary that can actually respond:

1async function fetchUser(id) {
2  const response = await fetch(`/api/users/${id}`);
3  if (!response.ok) {
4    throw new Error("User request failed");
5  }
6  return response.json();
7}
8
9async function showUserProfile(id) {
10  try {
11    const user = await fetchUser(id);
12    renderUser(user);
13  } catch (error) {
14    showError(error.message);
15  }
16}

This keeps transport concerns low in the stack and user-facing behavior high in the stack.

Keep Async Boundaries Meaningful

A good rule is that an async function should do at least one of these:

• start or coordinate asynchronous work
• transform results into a higher-level concept
• enforce sequencing rules
• define an error boundary

If it does none of those, it may not need to exist.

This also helps during refactoring. If a function exists only to await another function and return the same value, remove it or merge it upward.

Prefer Structured Concurrency Over Callback Trees

The healthiest async code usually has a shape you can describe in one sentence, such as "load three independent resources, then render" or "save the order, then publish an event." If the flow cannot be summarized that way, the nesting may be hiding too many responsibilities in one place.

Breaking the workflow into one orchestration function plus a few well-named helpers often makes the async structure shallower without changing the number of awaited operations.

Common Pitfalls

The biggest pitfall is assuming nested async code is bad because it is nested. Readability and correctness matter more than the number of layers.

Another problem is serializing independent work with repeated await calls. That often makes code slower and more verbose at the same time.

Over-handling errors is also common. Re-wrapping every exception at every layer can obscure the original cause instead of clarifying it.

Finally, watch for utility functions marked async only out of habit. If a function returns the result of another promise directly and adds no behavior, it may be an unnecessary abstraction.

Summary

• Multiple nested async methods are not inherently a problem.
• The real risks are unclear flow, duplicated abstraction, and accidental sequential execution.
• Use Promise.all when independent work can happen concurrently.
• Let errors travel to the layer that can handle them meaningfully.
• Keep each async function responsible for a real piece of orchestration or business logic.