How I Stopped Shopify's GraphQL API From Throttling My App (Parallel Query Patterns That Actually Work)

A dashboard I built was taking 4+ seconds to load. Products, orders, inventory, customer data — each query waited politely for the one before it to finish. Classic sequential bottleneck.

The fix was parallelism. But naive parallelism on Shopify’s GraphQL API gets you throttled fast, because it doesn’t count requests — it counts cost. So I had to learn how to go parallel and stay under the rate ceiling.

This post is everything I wish I’d known before I started. Code included.

Why sequential queries are the silent killer

Picture a dashboard loading three things:

• Product data
• Order history
• Inventory counts

Sequential, you pay the sum of all three. Parallel, you pay only the slowest single request. At scale, that gap is the difference between a snappy app and one users abandon.

First, understand the cost model (this is the whole game)

Shopify doesn’t limit you by request count. It uses a leaky-bucket cost system. Every query drains points; the bucket refills at a fixed rate.

Plan Bucket Size (points) Restore Rate (points/sec) Standard 1,000 50 Advanced 2,000 100 Plus 10,000 500

Every parallel request you add drains the bucket faster. So before you parallelize anything, read the extensions field that comes back on every response:

const { data, extensions } = await response.json();

console.log(extensions.cost);
// {
//   requestedQueryCost: 12,
//   actualQueryCost: 8,
//   throttleStatus: {
//     maximumAvailable: 1000,
//     currentlyAvailable: 920,
//     restoreRate: 50
//   }
// }

Enter fullscreen mode Exit fullscreen mode

That throttleStatus block is your fuel gauge. Tune everything else around it.

Pattern 1: Controlled concurrent batching

The naive version is just Promise.all:

const [products, orders, customers] = await Promise.all([
  fetchProducts(),
  fetchOrders(),
  fetchCustomers(),
]);

Enter fullscreen mode Exit fullscreen mode

This works for a handful of independent queries. But fire 50 at once and you’ll drain the bucket instantly. The fix is a concurrency limiter — cap how many run simultaneously:

import pLimit from "p-limit";

const limit = pLimit(5); // max 5 in flight at any time

const results = await Promise.all(
  productIds.map((id) => limit(() => fetchProduct(id)))
);

Enter fullscreen mode Exit fullscreen mode

Five concurrent requests is a safe starting point. Watch your throttleStatus, then push it up or down.

Pattern 2: Aliasing — many queries, one request

If you already know the IDs, you don’t even need multiple network calls. GraphQL lets you alias the same field repeatedly inside one query:

query {
  first: product(id: "gid://shopify/Product/1") { title }
  second: product(id: "gid://shopify/Product/2") { title }
  third: product(id: "gid://shopify/Product/3") { title }
}

Enter fullscreen mode Exit fullscreen mode

One round trip, three products. The catch: the cost is the sum of all aliases, so don’t pack so many in that a single query drains your bucket. Group enough to save round trips, not so many that you self-throttle.

Pattern 3: Parallel pagination via segmentation

Cursor-based pagination is inherently sequential — you can’t know page 2’s cursor until page 1 returns. So you can’t naively parallelize it.

The trick is segmentation. Split the dataset by a known field (date range, ID range), then paginate each segment in parallel:

const segments = [
  { query: "created_at:>=2026-01-01 created_at:<2026-04-01" },
  { query: "created_at:>=2026-04-01 created_at:<2026-07-01" },
];

const limit = pLimit(2);
const pages = await Promise.all(
  segments.map((seg) => limit(() => paginateAll(seg.query)))
);

Enter fullscreen mode Exit fullscreen mode

Each segment paginates independently. Just remember each one still burns points, so coordinate your concurrency.

Pattern 4: When to stop parallelizing and use Bulk Operations

Here’s the counterintuitive part: sometimes parallelism is the wrong answer. If you need every product or every order, stop fighting rate limits and use the Bulk Operations API. It runs your query async on Shopify’s servers and hands you a downloadable file. No throttling.

Quick decision table:

Scenario Best approach Few known records Query aliasing Real-time dashboard Concurrent batching Full catalog export Bulk operations Paginated lists Parallel pagination

Pattern 5: Coalesce duplicate in-flight requests

Two components both asking for the same product? Don’t fire two queries. Coalesce them — detect the identical in-flight request and have both callers await the same promise:

const inFlight = new Map();

function dedupedFetch(key, fetcher) {
  if (inFlight.has(key)) return inFlight.get(key);

  const promise = fetcher().finally(() => inFlight.delete(key));
  inFlight.set(key, promise);
  return promise;
}

Enter fullscreen mode Exit fullscreen mode

Pair this with response caching and you eliminate a huge chunk of parallel load before it ever reaches Shopify.

Backpressure: mirror Shopify’s bucket on your side

The cleanest way to never get throttled is to model the bucket locally. Run your own token bucket — acquire a token before each request, refill at Shopify’s restore rate. No token, you wait. Your app physically cannot exceed the allowed rate.

For high-volume systems, push this into a real queue so spikes get absorbed and metered instead of slamming the API all at once.

Handle throttles gracefully (because they’ll still happen)

Even with good planning, a traffic spike or an unexpectedly expensive query pushes you over. When Shopify returns THROTTLED, never just retry immediately. Use exponential backoff with jitter:

async function withBackoff(fn, attempt = 0) {
  try {
    return await fn();
  } catch (err) {
    if (!isThrottled(err) || attempt >= 5) throw err;
    const base = 2 ** attempt * 500;
    const jitter = Math.random() * 500;
    await sleep(base + jitter);
    return withBackoff(fn, attempt + 1);
  }
}

Enter fullscreen mode Exit fullscreen mode

The jitter is the important bit — without it, all your retries fire at the same instant and you get a thundering herd.

Design for partial failure

In a parallel batch, one request can fail while the rest succeed. Don’t let Promise.all reject the whole thing. Use Promise.allSettled and handle each outcome:

const results = await Promise.allSettled(tasks);

const succeeded = results.filter((r) => r.status === "fulfilled");
const failed = results.filter((r) => r.status === "rejected");

// retry only the failures

Enter fullscreen mode Exit fullscreen mode

Degrade gracefully. A single timeout shouldn’t nuke an entire batch.

Measure everything

You can’t tune what you don’t watch. The four metrics I track:

Metric What it tells you Throttle rate How often you hit limits Average query cost Per-request efficiency Concurrent request count Active parallelism level Retry frequency System stability

High throttle rate → dial concurrency down. Consistently low utilization → push it up. Set alerts on throttle spikes so you catch problems before users do.

The payoff: parallelism lowers your bill too

This isn’t only about speed. Efficient batching, coalescing, and caching all cut redundant calls. Fewer calls = lower API consumption = smaller bills and more headroom. The goal isn’t just faster queries — it’s faster queries that cost less.

TL;DR

1. Read the cost model first. It counts cost, not requests.
2. Batch with a concurrency limiter, not raw Promise.all.
3. Alias known IDs into single requests.
4. Segment to parallelize pagination.
5. Use Bulk Operations for full exports.
6. Coalesce + cache to kill duplicate calls.
7. Add backpressure, jittered backoff, and allSettled.
8. Monitor and tune from real data.

I write about Shopify performance and API architecture. The full, deeper version of this guide lives on my company blog. If you’re scaling a Shopify app and hitting these walls, that’s the kind of work we do at Kolachi Tech.