Parallel vs. Sequential Data Fetching

The plain-language idea

The previous lesson's fix — firing independent requests together instead of waiting on each one in turn — only works when the requests are actually independent. The real skill isn't "wrap everything in a parallel call," it's correctly classifying each pair of requests as one of two cases:

• Genuinely independent — neither request needs data from the other to know what to ask for. Fetching a user's profile and fetching their notification count can run at the same time; the notification count doesn't need anything the profile fetch returns.
• Genuinely sequential — the second request literally cannot be constructed until the first one returns. Fetching a user by an email address, then fetching that specific user's orders by the id the first request just returned, is a real dependency chain, not a fixable performance bug. There's no way to know which user's orders to ask for before the first request resolves.

Mistaking the second case for a fixable waterfall and trying to force it into a parallel call doesn't actually work — the second request would have to run with a value it doesn't have yet.

See it in a real thing: telling the two cases apart

// Genuinely independent — parallelize
const [profile, notifications] = await Promise.all([
  fetchProfile(userId),
  fetchNotificationCount(userId),
]);

// Genuinely sequential — cannot parallelize, the second call needs the first's result
const user = await fetchUserByEmail(email);
const orders = await fetchOrdersForUser(user.id);

A common middle-ground case: even inside a sequential chain, there's often a genuinely independent piece that can still run alongside it.

// The dependent chain and an independent fetch, running together
const [user, appConfig] = await Promise.all([
  fetchUserByEmail(email),
  fetchGlobalConfig(), // doesn't depend on the user at all
]);
const orders = await fetchOrdersForUser(user.id); // still has to wait on `user`

fetchGlobalConfig doesn't need anything about the user, so it doesn't have to wait for fetchUserByEmail just because they happen to be needed on the same page. Only fetchOrdersForUser has a real reason to wait, because it needs user.id.

What people usually miss

Watch out

• Reflexively wrapping everything in a parallel call doesn't work on real dependencies. If a request needs a value from an earlier response, forcing it into the same parallel batch just means it runs with undefined, or the code doesn't compile/type-check because the value genuinely isn't available yet.
• A dependency chain isn't automatically "the whole page must be sequential." Even when one part of a page has a real, unavoidable dependency chain, other data the page needs (global config, static reference data, anything not derived from the chain) can still be fetched in parallel alongside it.
• The judgment call is per pair of requests, not per page. A page can correctly mix parallel groups and sequential chains at the same time — treating "parallel vs. sequential" as one page-wide setting misses the real, request-by-request nature of the question.
• A request that's technically possible to reorder isn't the same as one with no dependency. Sometimes a backend could offer a combined endpoint to avoid the sequential chain entirely — that's a real, valid fix too, but it's an API-design change, not a fetch-ordering change on the frontend.

Why this matters in interviews

"Would you fetch these in parallel or sequentially?" for a scenario with a mix of dependent and independent requests is a real, common follow-up to any waterfall question, and correctly identifying which specific requests have a real dependency — rather than defaulting to either "always parallelize" or "always sequential" — is what separates surface-level pattern matching from actually reasoning about the data.