intermediate30 minby DevFox

Async Patterns and Concurrency

Running work in parallel versus in sequence, all versus allSettled versus race, cancelling with an abort signal, and the awaited loop that made everything ten times slower.

TypeScript
Async

The import job fetches eight thousand records. Written as a loop with an await inside, it takes forty minutes. Rewritten with Promise.all, it opens eight thousand connections at once, gets rate-limited, and fails — so somebody puts the loop back.

Neither extreme is right. By the end of this lesson you will bound how much runs at once, cancel work nobody is waiting for, handle partial failure without losing the successes, and recognise the shapes that turn concurrent work into sequential work by accident.

Sequential, concurrent, or bounded

typescript

for (const id of ids) {
  results.push(await fetchRecord(id));       // one at a time
}

const results = await Promise.all(ids.map(fetchRecord));   // all at once

One at a time

Safe, and forty minutes.

Each request waits for the last. Nothing can overwhelm anything, and nothing finishes either.

All at once

Fast, and eight thousand connections.

Promise.all starts every request immediately. Your memory, your file descriptors and the other service all find out together.

A fixed number at a time

Fast, and ten connections.

Ten workers, each taking the next item when it finishes. The only version you can predict the behaviour of.

Eight thousand records, and three ways to ask for them

So the answer is a limit:

typescript

async function mapWithLimit<T, R>(
  items: readonly T[],
  limit: number,
  fn: (item: T) => Promise<R>,
): Promise<R[]> {
  const results: R[] = new Array(items.length);
  let next = 0;

  async function worker(): Promise<void> {
    while (next < items.length) {
      const index = next++;
      results[index] = await fn(items[index]!);
    }
  }

  await Promise.all(
    Array.from({ length: Math.min(limit, items.length) }, worker),
  );

  return results;
}

typescript

const records = await mapWithLimit(ids, 10, fetchRecord);

Ten workers, each taking the next item when it finishes. Order is preserved because each writes to its own index. Memory is bounded, the service sees ten connections, and forty minutes becomes four.

Libraries provide this — p-map, p-limit — and the implementation is worth reading once because the shape appears everywhere.

The awaits that are secretly sequential

Bad — independent work awaited in sequence.

typescript

async function loadDashboard(userId: string): Promise<Dashboard> {
  const user = await fetchUser(userId);
  const photos = await fetchPhotos(userId);
  const settings = await fetchSettings(userId);

  return { user, photos, settings };
}

Good — started together, awaited together.

None of the three needs the others, and the first version takes their sum — three hundred-millisecond calls become nine hundred milliseconds of a page load, for nothing. The second takes the slowest.

This is the most common performance problem in async code, and it is invisible in review because each line looks correct. The tell is an await whose result the next line does not use.

The related shape from the foundations course, worth repeating because it is a bug rather than a slowdown:

map does not wait. It returns an array of promises, and the code after it runs immediately.

Partial failure

Promise.all rejects as soon as anything does, and you lose the results that succeeded:

Promise.allSettled never rejects:

Each result is a discriminated union narrowed by status — the pattern from the unions lesson, in the standard library.

Which to use is a product question, not a technical one.

Promise.all

All or nothing.

A transaction, a set of writes that must agree. Nineteen successes and one failure is a state nobody wants to be left in, so the whole thing rejects.

Promise.allSettled

Best effort.

A dashboard, a batch import, a page of independent widgets. Nineteen out of twenty is genuinely useful, and the one failure is a log line rather than an outage.

Ask what a half-finished run is worth to whoever asked for it

The third, Promise.any, resolves on the first success, which suits querying several mirrors for whichever answers first.

Note that Promise.all rejecting does not cancel the other work. Those requests continue, and their results are discarded. Stopping them needs the next section.

Cancellation

A promise cannot be cancelled. What you cancel is the operation underneath, with an AbortSignal:

The two places this matters constantly.

A timeout, which nothing has by default:

Without one, a service that accepts the connection and never answers holds your request forever, with no error and no log line.

Work that is no longer wanted — a search-as-you-type where the user typed another character, a component that unmounted:

Without that, responses arrive out of order and an older, slower one overwrites a newer one — results for "lis" replacing results for "lisbon".

Passing the signal through your own functions is worth doing from the start:

Retrofitting cancellation into a call stack that does not thread it is considerably more work than adding the parameter now.

Combine several with AbortSignal.any([...]) — a timeout and a user cancellation together.

Retrying, and not making it worse

Three details carry the weight, and they are the same ones from the AI course applied here.

isRetryable. A 400 will fail identically five times; a 503 may not. Retrying what cannot succeed turns one fast failure into five slow ones.

Exponential backoff. Doubling the wait gives a struggling service room to recover instead of adding to the load.

Jitter — the random component. Without it, a hundred clients that failed together retry together and fail together again.

And the rule that is easy to miss: do not retry a request that creates something unless the server supports an idempotency key. A POST that timed out may have succeeded with only the response lost, so retrying creates a second order.

Sequences that must stay sequential

Not everything should be parallelised. Two cases:

Order matters. Applying a list of updates where each depends on the last is a for...of with await, deliberately.

A resource allows one at a time. A rate limit of one request per second, a lock, a single writer.

The mistake to avoid is a queue built from a chain:

That works and the catch is essential — without it, one failure poisons the chain and everything queued afterwards rejects. It is the kind of detail that makes a hand-rolled queue worth replacing with a library once it matters.

A cheat sheet to keep

Where to go next

You can now run work at a rate a service can take, keep the successes when some of it fails, stop what nobody is waiting for, and spot the await that quietly made everything sequential. The habit worth adopting today is threading an AbortSignal through new async functions — it costs one optional parameter and cannot be retrofitted cheaply.

Next is Module Resolution, ESM, and CJS, which is the subject behind the most confusing errors in this ecosystem: an import the checker accepts and the runtime rejects.

Before you move on, find three sequential awaits in your code where none uses the previous result, and combine them with Promise.all. Time the page or the endpoint before and after. It is usually the largest single improvement available for the least work.