Designing for 100k RPS: What We Changed in the Storefront Architecture

A viral product launch should be a celebration. The brand posts a video, an influencer shares it, traffic spikes 50x in 20 minutes, and the orders pour in. We have seen storefronts handle exactly that — and we have seen storefronts where that same scenario means frantic Slack messages, a database that stopped responding, and a founder watching sales evaporate in real time. The difference was not server capacity. It was architecture.

We set 100,000 requests per second as a design target for QuantumOS X3 storefronts. Not as a marketing claim — as an engineering constraint that shaped every decision we made about how product pages are served.

The Core Insight: Most Requests Should Never Hit a Server

At 100k RPS, even a 10ms server response takes significant compute. But most requests to a storefront are for content that changes slowly — product pages, category listings, brand pages. A product description does not change 100,000 times per second. It changes a few times per day, when a merchant updates it in the admin.

The architecture implication: these pages should be served from CDN cache, not computed on demand. The server should be involved in generating a product page response once per cache expiry window, not once per visitor. At our cache hit rates during peak traffic, the server sees fewer than 2% of total requests. The CDN absorbs 98%.

ISR with Per-Tenant Cache Namespacing

Incremental Static Regeneration (ISR) is how we achieve this. When a product page is first requested after a cache expiry, a background revalidation request fires to regenerate the page. Visitors during revalidation see the stale cached page — still fast, still correct, just slightly behind. When revalidation completes, the cache updates and all future visitors get the new page.

In a multi-tenant storefront, ISR requires per-tenant cache namespacing. Aaladipattiyan's product cache must never mix with TVS Electronics' product cache. We namespace all cache keys by tenant_id and theme hash — so a theme change for one tenant automatically invalidates only that tenant's cached pages, not the entire CDN cache.

Edge Rendering for Dynamic Personalization

Not all content can be cached. Personalized recommendations, loyalty point balances, cart state — these are per-user and cannot be shared across visitors. We handle these at the edge using a pattern we call edge enrichment: the base page is served from CDN cache, and a lightweight edge function injects personalization slots from a user-specific edge cache (keyed by session ID) before delivering the response. The personalization lookup takes under 5ms because it reads from an edge-local key-value store, not a central database.

Database Connection Architecture

The failure mode that kills storefronts under peak traffic is usually not CPU or memory — it is database connection exhaustion. A Postgres server has a finite number of connections. When traffic spikes, naive architectures open one connection per request. At 100k RPS, that is 100,000 simultaneous Postgres connections — which a single database server cannot handle.

Our connection architecture uses PgBouncer in transaction pooling mode, multiplexing thousands of application connections onto tens of database connections. A database connection is held only for the duration of a single transaction — typically under 5ms. Between transactions, it returns to the pool. At 100k RPS, the database sees a steady pool of 200 connections handling all the traffic, rather than 100,000 connections trying to open simultaneously.

CDN Strategy: Cache Everything Cacheable, Route Everything Else to the Right Origin

Our CDN (Cloudflare) is configured with:

• Aggressive cache-control headers on product pages, category pages, and static assets
• Cache key rules that include tenant_id and locale to prevent cross-tenant or cross-locale cache pollution
• Automatic cache invalidation webhooks triggered by product and category updates in the admin
• Smart routing that sends cache misses to the nearest origin region — typically under 30ms additional latency

The result: p50 TTFB under 30ms (CDN cache hit), p95 TTFB at 92ms (including cache misses). At 100k RPS, we have never seen origin servers above 40% CPU utilization because the CDN absorbs the traffic that does not require fresh computation.

What This Means for a Merchant's Biggest Day

When an Aaladipattiyan launch goes viral — as karupatti products sometimes do during festival seasons — the storefront does not slow down. Traffic spikes are absorbed by the CDN. The database handles the order write load because read load (product pages) is not reaching it. The merchant sees high order volume and fast response times at the same time, not a tradeoff between them.

That is the design goal. Architecture is the competitive advantage that is invisible until the moment it matters most.

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