How does JavaScript's Promise.allSettled() differ from Promise.all(), and when would you use each?

Promise.all() — Fail Fast

const [product, reviews, recs] = await Promise.all([
  fetchProduct(id),
  fetchReviews(id),
  fetchRecommendations(id)
]);
// If ANY promise rejects, the ENTIRE thing rejects
// Reviews API down? → User sees nothing. Bad UX.

Promise.allSettled() — Wait for All

const results = await Promise.allSettled([
  fetchProduct(id),
  fetchReviews(id),
  fetchRecommendations(id)
]);

// results = [
//   { status: 'fulfilled', value: {...} },  // product
//   { status: 'rejected', reason: Error },   // reviews
//   { status: 'fulfilled', value: {...} },   // recs
// ]

const product = results[0].status === 'fulfilled' ? results[0].value : null;
const reviews = results[1].status === 'fulfilled' ? results[1].value : [];
const recs = results[2].status === 'fulfilled' ? results[2].value : [];

// Show what we have, graceful fallback for failures

Comparison

Method	Behavior	Use Case
Promise.all()	Rejects on FIRST failure	All must succeed or nothing
Promise.allSettled()	Waits for ALL, never rejects	Best-effort, partial results OK
Promise.race()	First to settle (fulfilled OR rejected)	Timeouts, fastest response
Promise.any()	First to FULFILL (ignores rejections)	Fallback servers, try multiple

Production Pattern: Graceful Degradation

async function loadProductPage(id: string) {
  const results = await Promise.allSettled([
    fetchProduct(id),     // Critical
    fetchReviews(id),     // Nice to have
    fetchRecommendations(id), // Nice to have
  ]);

  // Product is critical — if it fails, show error page
  if (results[0].status === 'rejected') {
    throw new Error('Product not found');
  }

  return {
    product: results[0].value,
    reviews: results[1].status === 'fulfilled' ? results[1].value : [],
    recommendations: results[2].status === 'fulfilled' ? results[2].value : [],
    partialFailure: results.some(r => r.status === 'rejected'),
  };
}

This pattern ensures users see something useful even when some services are degraded — a key principle of resilient frontend architecture.