During a retail promotion, shoppers open product details and recommendation sections across the website and mobile app. Many visits need the same product information, even when the exact order and ranking of recommendations differ. Repeated API reads compete with live commerce for origin capacity, slowing responses for shoppers evaluating items. Delivery teams need reusable data close to shoppers, with clear rules for refreshing it when products or offers change.
How Harper addresses API caching and personalization
Harper works behind your existing CDN or API gateway, bringing product data and recommendation logic closer to shoppers. It reuses cached product details to reduce repeat calls to your commerce platform, while calculating recommendations separately for each shopper.
Each Harper region runs the recommendation engine, API logic, and product cache together. Harper Fabric manages data replication, routing, and failover across regions, giving teams fewer systems to operate as they expand into new markets.
Your commerce platform remains the source of truth. When products or offers change, an integration clears affected cached data so the next request retrieves the updated information. Product details can be reused across shoppers, while personalized recommendations and responses stay private.
Product and offer changes start in your commerce platform. An integration clears affected copies in Harper and the gateway, so the next request retrieves updated data. Catalog management and the Product API are shown separately for clarity; both can belong to the same commerce system.
Alternatively, the common architecture
With a conventional stack, teams must run separate APIs, recommendation services, and caches in every region—and keep them updated and working together through traffic spikes and outages. That complexity makes this approach impractical for commerce teams without dedicated infrastructure specialists. Keeping everything centralized is simpler, but leaves shoppers waiting on distant systems. The diagram below shows what teams would need to build and manage.
Where complexity accumulates
When an offer changes, every region needs the update—or shoppers may see an old price. When a region fails, traffic moves elsewhere, where empty caches can send a surge of requests to the commerce platform. Teams must keep these changes and recovery steps coordinated as traffic grows and new markets are added.
Why Harper matters
Harper makes regional personalization practical by bringing recommendation logic and product data together, with fewer systems for your team to manage.
- Faster experiences. Run recommendations and serve reusable product details close to shoppers.
- Less origin work. Reduce repeated product requests, leaving more commerce capacity for transactions and creating opportunities to lower infrastructure costs.
- Easier expansion. Bring the same experience to new regions without assembling a separate application and cache stack in each one.
Public implementation references
These public HarperFast components provide starting points for the architecture:
- Product Recommendations runs recommendation logic inside Harper, using browsing associations and product data to return session-aware suggestions. It also fetches and caches product details from an origin API.
- Site Cache supports page and API caching, configurable cache lifetimes, bypass rules and targeted invalidation.
Integrate these components with your commerce platform and product-change workflow. Define when cached data expires, keep personalized responses private, and validate final prices and availability with the commerce platform.
Start with one shopper journey
Pilot a product page or recommendation placement. Compare response times by region, origin requests, and operating costs, then test product updates and regional outages. Measure shopper engagement or conversion separately to establish the business impact.
Bring your busiest product APIs and freshness requirements to a Harper architecture workshop to define the pilot.





