Storefront X3 — Edge-Rendered Commerce That Survives Flash Sales

Most platforms treat headless and hosted as two separate products maintained by different teams. Features land in one mode months before they appear in the other. Storefront X3 eliminates this entirely: there is one React renderer and one component registry. When you run in hosted mode, the platform owns the edge deployment. When you run in headless mode, you deploy the same renderer package to your own infrastructure. The content model, section registry, section configuration schemas, personalisation rules, AB tests, theme tokens — everything is stored in the platform and consumed identically by both modes.

Migrating between modes is a deployment-configuration change, not a content model rebuild. You do not need to re-enter product descriptions, re-author banners, or rewire checkout. We tested this with a 380-SKU electronics brand that switched from hosted to a Cloudflare Workers deployment in 4 hours with zero customer-visible downtime.

Storefront X3 pre-renders every category, product, and landing page at build time and pushes the HTML to edge nodes across 310 PoPs. Subsequent requests are served from memory — no database round-trip, no server compute. The median response from cache is 4ms at p50, 11ms at p95.

When a product price changes in the admin, the platform emits a targeted invalidation event scoped to that product's URL, any category pages it appears on, and any bundles it participates in. Invalidation fan-out completes in under 800ms globally. During the invalidation window, stale-while-revalidate ensures the edge continues serving the previous cached page rather than falling through to origin — eliminating the cold-cache latency spike that plagues deploy-based cache invalidation strategies.

Flash-sale operators frequently update prices for thousands of SKUs simultaneously. X3 batches these invalidation events, coalesces overlapping category invalidations, and respects a configurable per-page revalidation budget to prevent thundering-herd on origin. Real-time price changes reflect at the edge within 30 seconds for 99th-percentile product catalogs.

Every visual section in Storefront X3 — hero banners, product grids, testimonial sliders, countdown timers, video embeds, FAQ accordions — is a typed React component registered in the section registry. Each section exports a Zod configuration schema. The admin Section Builder reads that schema at runtime and auto-generates a structured form: string fields become text inputs, enum fields become dropdowns, boolean fields become toggles, image fields open the media picker with upload + CDN delivery built in.

Merchants drag sections onto the page from the palette, reorder them, configure them in the sidebar, and see a real-time preview in the right panel. The preview is the actual renderer running in an iframe pointed at the staging environment — not a simulated mock. What the merchant sees in the builder is bit-for-bit identical to what customers see in production.

Section configurations are versioned. Every save creates an immutable snapshot. Undo/redo traverses this snapshot history with O(1) state restoration — the system diffs snapshots at section granularity so reverting one section does not affect siblings. Publishing pushes the live configuration atomically via a single write to the edge config store, which propagates to all edge nodes in under 2 seconds.

True user-level personalisation at scale is an infrastructure nightmare: you cannot cache user-specific HTML at the edge without either exploding your cache key space or falling back to uncacheable server-rendered responses. X3 solves this with segment-level caching, which gives you 90% of the conversion lift at 1% of the infrastructure cost.

When a visitor hits the storefront, the edge worker reads lightweight signals: the segment cookie set on last visit, the geographic region from the request metadata, the device class (mobile/desktop/tablet) inferred from the User-Agent. It maps these to a segment identifier — for example, "IN-mobile-returning" or "US-desktop-new". The edge worker then serves the pre-cached HTML variant for that segment. No origin request. No database lookup.

The admin rule builder lets merchandisers define segments and configure what changes per segment: the hero image and headline, the promotional badge on product cards ("Free shipping for you"), the featured products grid order, and which payment methods appear first at checkout. Each variant is pre-rendered and cached separately at the edge. X3 supports up to 512 concurrent segments per storefront. A/B test variants count as segments, so personalization and testing share the same infrastructure.

Going international is not a plugin. It requires every layer of the commerce stack — pricing, tax, fulfilment, payment methods, content, and URLs — to be aware of market context simultaneously. Storefront X3 models this as Market Bundles: a named configuration that ties together a locale (language + region), a display currency with CLDR-correct formatting rules, a tax strategy (inclusive or exclusive, VAT-registered or not), a shipping zone set, and an allowed payment method list. Switching a visitor to a different market switches all of these atomically from a single market identifier.

Currency display uses CLDR data directly: ₹1,23,456.78 in India (lakh grouping), $1,234.56 in the US, 1.234,56 € in Germany. FX rates are updated every 15 minutes from a blended rate feed; merchants can add a spread margin per currency. Prices can be set explicitly per market or derived from a base currency with the spread applied.

The multilingual system supports RTL layouts (Arabic, Hebrew, Urdu) with automatic logical property substitution (margin-inline-start instead of margin-left) at the CSS token layer — no theme modifications required. Each language-market combination gets its own hreflang tag set and sitemap entry. The translator workflow in the admin shows content coverage per locale, surfaces untranslated strings, and tracks translation status (draft / in-review / published) per content block.

The Storefront X3 PWA layer is built on Workbox with a configuration optimized for commerce: shell caching for the app frame, network-first for cart and checkout endpoints (where stale data is harmful), and stale-while-revalidate for product listing pages (where a slightly stale page is fine and speed matters more). The service worker is generated per-tenant at build time so cache strategies can be tuned per page type.

Install prompts appear on the second visit using the beforeinstallprompt event, with a configurable deferral strategy. The installed experience runs in standalone display mode with the tenant's brand colors in the address bar theme-color meta tag and a full-screen splash screen using the tenant's uploaded logo. On Android, the TWA (Trusted Web Activity) wrapper allows listing the PWA on the Google Play Store as a native-feeling app.

Web Push notifications are wired directly to the platform's customer record. Subscription tokens are stored against the unified customer profile alongside email and SMS opt-ins, so a single broadcast from the admin can reach customers across all three channels simultaneously. Push payloads support deep links into product pages, cart, and order tracking. Update deployment to the service worker is instantaneous — no App Store review, no staged rollout delay.

Third-party AB testing tools insert JavaScript that runs after the page loads and swaps DOM elements — the original variant flashes for 50–300ms before the test variant renders. This flicker degrades the user experience and inflates bounce rates on the test itself. X3 AB testing runs in the edge worker before any HTML is sent to the browser: the bucket assignment happens at request time, and the correct variant HTML is served directly. The browser never sees the original variant.

Bucket assignment is deterministic via a hash of the visitor's stable identifier (the session token) XOR'd with the experiment ID. The same visitor always gets the same variant across sessions and devices as long as they are logged in. Anonymous visitors are assigned on first visit and the assignment is stored in a first-party cookie that survives browser restarts but not private browsing — consistent with privacy regulations.

Significance is computed using a Bayesian model with a configurable prior. The admin dashboard shows posterior probability of each variant being the best, expected loss if you shipped the current leader right now, and uplift credible intervals at 90% and 95% confidence. Metrics are real commerce events — checkout initiated, order placed, revenue per visitor — not page views or clicks. You can pause an experiment mid-run, force-assign a specific variant for QA, or override the bucket for a specific customer ID from the admin.

Storefront X3 ships a white-label React Native shell for iOS and Android. The shell is thin: it handles system integrations (biometrics, push notification permission, camera for barcode scanning, haptic feedback, in-app review prompts) and loads the storefront renderer via a WebView bridge. Because the renderer is the same code running on web, all storefront updates are live immediately — the mobile app does not need an App Store update when the merchant changes their catalog, theme, or promotions.

Tenant configuration happens in the admin at Settings > Mobile App. Merchants upload their app icon, splash screen, and brand palette. They configure deep link routes, the bottom navigation tab structure, and whether to enable biometric login. The platform generates a signed build submitted to the App Store and Google Play under the tenant's developer accounts. Subsequent updates that only change renderer content go live without a new build submission.

Push notification tokens from the mobile app are stored in the same customer record as Web Push tokens and marketing email/SMS opt-ins. The unified customer comms layer lets the platform pick the best channel per customer: if the customer has the mobile app installed and push enabled, mobile push is preferred over email for time-sensitive order status notifications. A server-driven force-update gate allows the platform to require a minimum app version before the user can proceed, preventing stale clients from hitting deprecated API endpoints.

The Storefront X3 theme system is built on a two-layer CSS variable architecture. The first layer is the global token set: color primitives (brand-500, accent-400, ink-950), typography scale, spacing rhythm, border radius, and shadow definitions. The second layer is the semantic token set: button-background, card-border-color, price-text-color — these reference global tokens and are what component stylesheets consume.

Merchants customise the semantic token layer in the admin theme editor. The editor shows a live preview of the storefront that updates in real time as tokens change. Saving a theme creates a new theme_overrides record in the database; the storefront picks up the override set on next request and injects it as a :root style block. From save to visible in the edge-cached preview is under 8 seconds: theme invalidation has its own fast-path that bypasses the full ISR revalidation pipeline.

Each tenant has exactly one active theme. Super-admins can create new themes in the qos_themes catalog. When a merchant first opens the theme editor, the platform clones the base theme into a tenant-owned draft so changes are isolated. The base theme stays intact and can be updated by the platform without affecting merchant customisations. Reverting to base is a single button click that deletes the theme_overrides record and invalidates the edge cache for that tenant.

Every content surface in Storefront X3 is managed through the CMS layer, not hardcoded. The news ticker — used by brands like Aaladipattiyan to announce flash sales, seasonal promotions, and delivery updates — is a CMS content type with scheduling: configure when it appears, when it disappears, and what it says, all without a developer. Banners, hero images, and promotional overlays follow the same pattern.

The landing page builder extends the Section Builder to standalone URLs. Merchants can create /sale/diwali or /brand/partnership pages with a custom section layout, their own SEO metadata, and tracking UTM parameters — without involving engineering. These pages are pre-rendered as ISR routes and cached at the edge like any other storefront page.

The blog CMS supports rich text (with embedded product references that resolve to live price and availability), author profiles, tag taxonomy, and a reading time estimate. Blog posts generate structured data (Article schema, BreadcrumbList) automatically. The FAQ CMS generates FAQ schema markup, improving search result appearance with expandable answers in Google. All structured data is injected server-side in the <head> — not client-rendered — ensuring it is indexed on first crawl.