Performance

Shop integrations handle potentially high volumes of data — thousands of products, frequent stock updates, and bursts of orders. Good performance practices ensure your integration stays responsive and doesn't hit rate limits.

Rate Limiting

VARIO ERP API Rate Limits

The VARIO ERP API enforces rate limits to protect system stability. The framework's Api class automatically handles HTTP 429 responses with exponential backoff, so your code doesn't need to implement retry logic for ERP API calls.

However, you should still be mindful of your request volume:

  • Batch VQL queries — Fetch multiple entities in one query instead of one query per entity

  • Avoid redundant requests — Cache data that doesn't change frequently

  • Spread load — Don't fire all requests at once; pace them over time

Platform API Rate Limits

External platforms (Shopify, Amazon, etc.) each have their own rate limits. Common patterns:

  • Request-based limits — X requests per second/minute (e.g., Shopify: 2 requests/second for REST)

  • Cost-based limits — Each API call has a "cost" and you have a budget per time window

  • Concurrent request limits — Maximum number of simultaneous connections

Handle platform rate limits in your sync logic:

async function syncWithRateLimit(items, requestsPerSecond)
{
  const delay = 1000 / requestsPerSecond;

  for (const item of items)
  {
    await syncItem(item);
    await new Promise(resolve => setTimeout(resolve, delay));
  }
}

Batching

VQL Query Batching

Instead of fetching one entity at a time, batch your queries:

Platform API Batching

Many platforms support bulk operations. Use them when available:

  • Bulk product updates — Send multiple product changes in one API call

  • Batch inventory updates — Update stock for multiple products at once

  • Bulk fulfillment — Mark multiple orders as fulfilled in one request

Queue Processing Optimization

Batch Size

Control how many queue items are processed in each cycle. The right batch size depends on:

  • Platform API rate limits

  • Processing time per item

  • Memory constraints

Start with a small batch size (10) and increase gradually while monitoring performance.

Priority Processing

Not all sync types are equally urgent. Prioritize:

  1. Stock sync — Most time-sensitive (prevents overselling)

  2. Order status sync — Customers expect timely updates

  3. Price sync — Important but less urgent

  4. Product sync — Can tolerate some delay

  5. Media sync — Lowest priority (large file transfers)

Deduplication

When the same entity triggers multiple webhooks in a short time (e.g., an article updated three times in 10 seconds), avoid processing all three:

  • Check if the entity is already queued before adding a new item

  • If already queued, skip or update the existing item's timestamp

  • The sync operation will fetch the latest data at processing time anyway

Caching

What to Cache

Data
Cache Duration
Rationale

Sales channel parameters

Minutes

Read frequently, change rarely

Mapping configurations

Minutes

Read on every sync, change via UI

Platform product IDs

Session

Needed for every sync operation

ERP master data (tax rates, units)

Hours

Changes very infrequently

What Not to Cache

  • Stock levels — Change too frequently

  • Prices — May be stale if cached

  • Order data — Must be current

Simple In-Memory Cache

Initial Sync Performance

The first-time sync of an entire product catalog is a special case. Strategies:

  • Paginate — Fetch products in pages of 100-500 from the ERP

  • Parallel processing — Process multiple pages concurrently (within rate limits)

  • Progress tracking — Store the current page/offset so you can resume after failures

  • Off-peak scheduling — Run initial syncs during low-traffic hours

VQL Query Optimization

  • Select only needed fields — Don't use SELECT *; specify exactly what you need

  • Filter in the query — Use WHERE clauses to reduce data before transfer

  • Use appropriate limits — Don't fetch 10,000 rows when you need 100

  • Avoid leading wildcardsLIKE '%value' is slow; prefer LIKE 'value%'

Last updated

Was this helpful?