Edge Functions vs. Serverless: The Right Architecture for Commerce

The first time a customer in Chennai waits 4 seconds for a product page to load, they do not think 'the server was cold.' They think 'this store is broken.' And they leave. They do not come back. Cold starts are not an infrastructure curiosity — they are a direct line to lost revenue, especially in mobile-first Indian commerce where attention windows are narrow and 4G connections are unforgiving.

This is why the edge-vs-serverless decision is not an academic architecture debate. It is a business decision with a measurable impact on conversion rates.

What Cold Starts Actually Cost

A serverless function — deployed to AWS Lambda, Vercel Functions, or Cloud Run — scales to zero when idle. When a request arrives, the runtime spins up a container, loads your code bundle, initializes your database connections, and then handles the request. On a warm instance, this is fast. On a cold start, this adds 200ms to 800ms of latency before your function even begins processing.

For a storefront serving a product listing page, that cold start happens on the first visitor of the day, on the first visitor after a quiet period, on the first visitor from a new region. These are often the highest-value visitors — someone who searched for your product and clicked through. They hit the longest wait time. That is backwards.

Edge Functions: Always Warm, Globally Distributed

Edge functions run inside CDN nodes. Cloudflare Workers, for example, runs in over 300 cities. When a customer in Coimbatore requests a product page, the nearest edge node — not a data center in Mumbai — handles the initial response. The function is always warm because it runs in an isolate model, not a container model. Startup time is measured in microseconds, not hundreds of milliseconds.

At QuantumOS X3, our storefront edge functions handle:

• Tenant resolution (which storefront does this hostname map to?)
• Theme token injection (CSS variables from the tenant's active theme)
• A/B test cookie assignment and variant selection
• Cache-control header computation based on content type
• Geographic routing for multi-region tenants

None of these need a database connection. They are pure logic with access to edge-cached data. Running them at the CDN node means a customer in Bangalore gets the same response latency as a customer in Mumbai — not because we have servers in both cities, but because the CDN does.

What Stays in Serverless

Not everything belongs at the edge. Edge functions have constraints — no long-lived connections, limited CPU time, no access to Node.js built-ins in some runtimes. The right workloads for serverless are:

• Order placement (writes to the database, triggers OMS events)
• Payment webhook handling (Razorpay, UPI confirmation callbacks)
• PDF invoice generation for GST compliance
• AI Copilot inference calls that may take 500ms to 2 seconds
• Bulk catalog imports and image processing

These workloads have a known latency budget that the user expects. No one expects order confirmation to be instantaneous — they expect it to be reliable. Serverless is the right home for reliability-critical, latency-tolerant work.

The Hybrid Pattern We Use

Our storefront architecture layers like this: the edge function handles routing, cache hits, and static-ish responses. A cache miss triggers a revalidation request to a serverless function that queries the tenant's dedicated Neon database, builds the response, and caches it at the edge for the next N seconds. The first visitor after a cache expiry waits for a serverless response. Every visitor after that gets the edge-cached version in under 100ms.

This is Incremental Static Regeneration (ISR) at the architecture level — not just a Next.js feature, but a principle: compute once, serve many times, recompute in the background when stale.

The Numbers

Our production p95 TTFB across all storefront tenants is 92ms globally. On a pure serverless architecture, achieving that number would require aggressive keep-warm strategies that partially defeat the cost benefits of serverless. With edge-first rendering, the 92ms is structural — it is what the architecture produces without tricks.

For an Indian SMB running their first online store on QuantumOS X3, this means their storefront is faster than most enterprise retailer sites on day one. That is not a feature. That is a compounding advantage — every millisecond of latency improvement compounds into conversion rate, into repeat purchase rate, into brand trust.

The architecture is the product. Choose it deliberately.

Subscribe to the QuantumOS Dispatch — weekly insights for commerce operators who want to compound their advantages.