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.

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

//   }

// }

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(),

]);

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)))

);

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 }

}

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)))

);

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:

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;

}

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);

  }

}

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

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:

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 .