Catalog and Inventory Sync

When a retailer changes a promotion or receives new stock, shoppers expect product pages, and store availability to reflect the change. Repeatedly fetching that information from central commerce systems can slow browsing and use capacity needed for orders. Teams need product, price, and availability data close to shoppers, with a reliable way to keep it current and keep browsing available when central systems slow down or fail.

How Harper addresses catalog and inventory sync

Harper keeps a regional copy of product, price, and store-availability data alongside the API that serves it. Shoppers can browse nearby data instead of repeatedly calling central commerce systems.

An integration brings in changes from your source systems in real time and checks for missed updates. Harper Fabric distributes the data and application across regions, managing replication, routing, and failover. If one Harper region becomes unavailable, traffic can move to a healthy region. This adds a separate, redundant browsing layer alongside your commerce systems.

If the central system becomes unavailable, Harper can keep serving stored browsing data within your freshness limits. Checkout, missing data, and information that must be checked live still depend on the commerce system. Your team defines when to show unavailable information rather than an outdated price or stock promise.

Product and stock changes flow through an integration built for your commerce systems. It applies updates in the right order and checks the regional data against the source.

Alternatively, serving from the commerce system

In a common setup, the website or app requests product details, prices, and availability from central commerce systems. Existing caching can answer some requests, but the rest travel back and wait for a response. Distant shoppers face longer round trips, and busy periods send more browsing traffic to systems also handling orders. Those systems may have their own redundancy, but browsing still depends on their availability when the cache can't serve a request.

Where delays and outages affect shoppers

A traffic spike can slow product browsing as requests compete with order processing for capacity. If the commerce service becomes unavailable despite its own redundancy, shoppers may also lose access to product details and availability. Harper adds a separate path for eligible browsing requests: regional copies can keep serving while the source recovers, and Fabric can route around an unavailable Harper region. Checkout still depends on the commerce system.

The impact can be substantial. During a major U.S. retailer’s one-hour origin outage, Harper served 2 million product-page requests from cached pages, preserving 80% of traffic. Shoppers could continue browsing while the retailer restored its systems.

Why Harper matters

Harper makes browsing faster and more resilient by serving product data from a separate regional layer. Your commerce systems continue to own orders and stock.

• Faster browsing. Serve product details and store availability close to shoppers.
• Less source-system work. Reduce repeated catalog requests, leaving more capacity for orders and creating opportunities to lower serving costs.
• Easier expansion. Bring browsing data closer to new markets while keeping your existing commerce systems.
• More resilient browsing. Keep eligible product information available during a source outage, with multiple Harper regions and failover protecting the serving layer itself.

Public implementation references

• Harper Ecommerce Template demonstrates product serving and a Next.js storefront backed by Harper, including caching and invalidation.
• Site Cache provides page and API caching with configurable lifetimes, bypass rules, and targeted invalidation where additional caching is needed.

These are starting points for serving and caching, not a complete catalog-and-inventory sync integration. Your implementation must connect the source systems, match product and location identifiers, handle delayed or duplicate updates, and repair missed changes. Define how old prices and availability may be before they must be checked again. Regional replication may take a second or two, so checkout must confirm price and reserve stock with the source system.

Start with one catalog

Pilot one commerce source, a manageable product set, and a few fulfillment locations. Measure browsing speed, update delays, source requests, and operating costs. Test a central-system outage separately from a Harper-region outage: confirm which browsing requests remain available, how traffic moves to healthy regions, and when stale data must stop being served. Verify checkout and recovery against the source of truth.

Bring your catalog owners, inventory systems, and freshness requirements to a Harper commerce data workshop to define the pilot.

‍