Maho Storefront: Sub-50ms E-commerce at the Edge

Architecture
Maho Storefront: Sub-50ms E-commerce at the Edge

Lightning-Fast Ecommerce with Edge Computing

The Maho Cloudflare Storefront delivers sub-50ms page loads worldwide by leveraging a sophisticated three-tier caching architecture at the edge. This isn't just another CDN setup - it's a complete rethinking of how e-commerce pages are served.

The Problem with Traditional E-commerce

Traditional Magento/Maho storefronts require every page request to travel to your origin server, execute PHP, query databases, and render templates. Even with caching layers like Varnish or Redis, you're still limited by:

  • Geographic latency - Users far from your server experience 200-500ms delays

  • Origin load - Every uncached request hits your server

  • Cache invalidation - Complex and error-prone

  • Scaling costs - More traffic = more servers

The Architecture

Maho Cloudflare Storefront Architecture

The diagram shows the complete request flow. Note the two distinct paths:

  1. Catalog pages (products, categories, CMS) -> Flow through the edge cache

  2. Dynamic operations (cart, checkout, search) -> Go directly to the Maho API

Three-Tier Caching: The Fast Path

For catalog pages, requests pass through three cache layers before ever reaching the origin:

Tier 1: Cloudflare Edge Cache (HTML)

The fastest layer. Full HTML pages are cached at Cloudflare's 300+ edge locations. Response time: ~1-5ms. This is standard CDN caching, but what makes our approach special is how we keep it fresh.

Tier 2: Cloudflare KV (JSON Data)

Product data, category structures, and CMS content are stored as JSON in Cloudflare's global key-value store. When edge cache misses, the Hono Worker reads from KV and renders HTML server-side using JSX templates. Response time: ~10-25ms.

Tier 3: Maho API (Origin)

The PHP backend is only hit when KV cache misses, during scheduled syncs, or for dynamic operations. With proper syncing, origin load drops to <5% of traditional setups.

The Freshness Problem - And Our Solution

The challenge with aggressive caching is staleness. How do you serve cached pages while ensuring customers see up-to-date prices, stock levels, and content?

Traditional approaches:

  • Short TTLs - Cache for 60 seconds, then refetch. High origin load.

  • Cache tags - Purge on change. Complex to implement, can cause cache stampedes.

  • Stale-while-revalidate - Serve stale, refresh in background. Better, but still requires origin checks.

Our Approach: Freshness Metadata + Throttled Revalidation

Every cached page includes hidden metadata about its content:

<div hidden
  data-freshness-type="product"
  data-freshness-key="product:elizabeth-knit-top"
  data-freshness-version="a8f3b2c1"  
  data-freshness-checked="1707753600"
/>

The version is a hash of the product's key attributes (price, stock, name). When the page loads, client-side JavaScript checks:

  1. Has 60 seconds passed since last check? If not, skip.

  2. Fetch current version from a lightweight API endpoint

  3. Compare versions - if different, trigger background refresh

This gives us the best of both worlds:

  • Pages load instantly from cache

  • Stale content is detected and refreshed within 60 seconds

  • Origin receives at most one check per URL per minute, regardless of traffic

URL Resolution: Resilience with Empty Cache

What happens when KV is empty - new deployment, cache flush, or missing data? The Worker doesn't know if /elizabeth-knit-top is a product, category, or CMS page.

Our solution: a URL Resolver API as fallback:

GET /api/url-resolver?path=elizabeth-knit-top
-> { "type": "product", "id": 421, "identifier": "elizabeth-knit-top" }

The Worker then fetches the full entity, caches it in KV, and renders the page. First visit is slower (~200-400ms), but subsequent requests are fast (~10-25ms).

Bot Protection: Rate Limiting 404s

Malicious bots hitting random URLs could overload the resolver. We track 404s per IP:

  • 30 404s in 5 minutes -> IP blocked for 15 minutes

  • Uses Cloudflare's Cache API as a distributed counter (no KV quota usage)

  • Blocked requests return 429 Too Many Requests immediately

Performance Results

unsafe:Performance Comparison: Traditional vs Edge

Real-world metrics from production:

Metric

Traditional

Edge

Improvement

TTFB (Time to First Byte)

200-800ms

8-25ms

10-30x faster

Full Page Load

1.5-3s

<500ms

3-6x faster

Origin Server Load

100%

<5%

95% reduction

Global Latency Variance

High (200-800ms)

Low (~20ms)

Consistent worldwide

Technology Stack

  • Cloudflare Workers - Serverless edge runtime (300+ locations)

  • Cloudflare KV - Global key-value storage with ~50ms reads worldwide

  • Hono - Ultralight web framework (~14kb) with JSX support

  • Stimulus + Turbo - Progressive enhancement without heavy JS frameworks

  • Maho API Platform - Symfony-based REST/GraphQL API

Try It Yourself

Experience the speed difference:

Open DevTools Network tab and watch the TTFB. Then compare to any traditional Magento store.

Built by Mageaustralia — Melbourne-based, building commercial Maho extensions + the Cloudflare Storefront this site runs on.