Excavator ACC is our client for this project. According to the project background supplied by the client, the site needs to support a catalogue of thousands of SKUs. We built a cross-border commerce site in which visitors receive storefront pages and static assets close to the edge, business requests enter a separate commerce backend, and product, order, session and search concerns are handled by services suited to each job.

This case study stays at the level of the public site and the project architecture. It does not disclose server addresses, credentials, secrets, internal hostnames, order data, traffic figures or other private client information. It also does not turn unverified availability, ranking, conversion or revenue outcomes into project results; those require production baselines and an agreed observation window.

Define the system boundaries first

When a catalogue reaches thousands of SKUs, the homepage is only the part of a commerce site that visitors see. Engineering still has to answer how product data is read, how categories and search paginate, how carts and checkout stay dynamic, how search indexes change, how images are delivered and what happens when background work gets slow.

We set four boundaries first: the storefront handles delivery and presentation, Medusa handles commerce, data services stay behind controlled network access, and indexes and caches may be rebuilt but never replace order data. Cloudflare, Next.js, R2, Medusa and the data services were placed around those boundaries.

Figure 1: after Cloudflare, storefront and commerce API requests take separate paths.

Storefront delivery and cache boundaries

For a site serving international buyers, the first request should not send every piece of work to the origin. We placed the Next.js storefront in Cloudflare’s edge runtime so that rendering, static assets and cacheable content can stay closer to visitors. R2 provides storage for the OpenNext incremental cache and site media.

Cache boundaries follow page responsibility. Product, category and editorial pages can use ISR or edge caching; carts, accounts, checkout and payment callbacks remain dynamic and explicitly avoid shared caching. Prices and inventory may use short-lived reads, but checkout must return to Medusa for server-side validation.

This is also an SEO and privacy boundary. Putting cart state, personal information or temporary pricing into a shared cache exposes data to the wrong sharing model and gives crawlers unstable page content. Cache policy has to follow page responsibility; it cannot be reduced to one global max-age header at the end.

Decouple commerce from storefront delivery

Medusa is the business core for products, carts, orders and transaction flows. Cloudflare Tunnel provides a controlled edge entry point for the commerce API, so the origin does not need to expose its application ports directly to the public internet. Inside the origin, a reverse proxy routes requests to Medusa.

We paid particular attention to boundaries: Store API handles storefront and purchase flows, administrative access should have a separate protection policy, and PostgreSQL, Redis and Meilisearch should remain on an internal network. With thousands of SKUs, search writes and full reindexes especially should not compete with storefront requests. Payment webhooks and third-party connections should use signature verification, idempotency, retries and traceable handling.

Tunnel addresses the origin’s exposure surface, not availability by itself. If multiple services share one failure domain, an infrastructure failure can still affect the API, database, cache and search together. We kept that boundary in the roadmap instead of treating Tunnel as a high-availability guarantee.

Give online requests and background work separate resources

A commerce backend does more than answer browser requests. Product sync, inventory updates, email, payment notifications, search indexing and scheduled jobs all consume CPU, database connections or Redis resources. When they share one process with the Store API, a slow job can slow down checkout as well.

The architecture separates the Medusa server and worker: the server focuses on Store API, Admin API and transaction requests; the worker handles subscribers, asynchronous workflows, scheduled jobs, follow-up webhook processing and search sync. They can use the same application image, but should have independent processes, restart policies and monitoring signals.

The split addresses a concrete operations problem: when a background queue grows, the team can observe, restart or scale the worker without taking the storefront transaction path with it.

The core of cache policy is invalidation

For commerce sites, a cache hit is only the first step. The important question is which pages must expire when a product changes. Publication status, price, promotion, inventory and category changes can affect product pages, category pages, search results and homepage modules.

For Excavator ACC, we split the change path into three actions: Medusa emits product or inventory events, background work updates Meilisearch, and a protected frontend revalidation endpoint clears relevant pages by product, category or collection. Editorial pages can keep longer ISR windows; prices and inventory can use shorter reads, while checkout always treats the commerce backend as authoritative.

Figure 2: business data, search indexing and page caching are separate layers with different update jobs.

A pressure model for thousands of SKUs

Once a catalogue reaches thousands of SKUs, the main problem becomes change propagation and resource isolation. One price adjustment may affect several variants and regions; one inventory sync may trigger search updates, product-page expiry and category recalculation; one full import executed inside the API process can consume database connections, memory and CPU.

We focused on four kinds of pressure.

  • Read pressure: product lists need explicit pagination, sort and filter allowlists, and controlled response sizes rather than unbounded deep pages or every field at once.
  • Write pressure: imports, price changes and inventory syncs should run as retryable background jobs, in batches, with protection against out-of-order updates to the same SKU.
  • Index pressure: Meilisearch is a search projection, not the business source of truth. Incremental updates need retries, full rebuilds need progress visibility, and a damaged index must be regenerable from Medusa / PostgreSQL.
  • Stability pressure: a failed cache invalidation, search task or third-party sync should allow partial degradation. Search being unavailable should not take product detail, cart and checkout down with it.
Figure 3: batch work is separated from visitor requests, while business data and the transaction path remain available when search or cache work fails.

SEO lives in route and data boundaries

Technical SEO in this project starts with routes, page jobs and link relationships rather than a final pass of meta tags: product pages explain what an item is, category pages organize collections, and editorial pages answer use-case or buying questions. Navigation connects those pages instead of forcing every distinction into one menu.

Edge rendering and incremental caching also require careful handling of canonicals, hreflang, structured data, cache headers and dynamic page boundaries. Public pages can be discovered and reused; accounts, carts, checkout and webhooks must not enter shared indexes or shared responses for convenience.

Internal links are part of the product path. A reader can move from our SEO growth service to the evidence-led method, then to a relevant case study or custom software service. Each link supports the next decision; none exists to fill the page with decorative cross-links.

The delivery boundary and the next stage

Figure 4: establish boundaries and recovery first, then add replicas and managed services as order volume and operations justify them.

The Excavator ACC project leaves a set of boundaries for the next stage: the storefront can be optimized independently, Medusa can separate server and worker responsibilities, PostgreSQL and Redis can move toward production-grade managed services, Meilisearch can be rebuilt when necessary, and Cloudflare Tunnel can evolve from one connector to more than one.

Those are executable paths, not reported growth outcomes. Once the site has production baselines, the useful measures will include edge cache hit rate, API P95 latency, background-job failure rate, search-sync delay, order-creation success rate and payment-webhook errors. A case study earns its next chapter only when those measures have an owner, a baseline and a defined observation window.

If you are building an independent commerce site that must balance international delivery, product discovery, transaction flows and maintainability, start with one important page type or business path. Our SEO growth service connects search structure, content and technical implementation; our custom software service covers storefront applications, business APIs and internal tools when the project needs more than a marketing page.