Start a project
Advanced

Indrani Infrastructure: Analyzing the Next.js E-Commerce Stress Test

8 min readBy Ajay Thakkar
Project:Indrani Jewelers
Stack:
Next.jsVercelPerformance TestingServerless Architecture

Testing your infrastructure under heavy concurrent load is critical for enterprise scale. Discover how the Indrani Jewelers platform achieved a zero percent failure rate during our rigorous Next.js e-commerce stress test.

When engineering high-traffic web applications, assuming your platform will scale is a dangerous gamble. You must mathematically prove it. We recently subjected the Indrani Jewelers infrastructure (hosted at https://www.indranijewells.com) to a rigorous, high-concurrency e-commerce stress test to identify our architectural bottlenecks, measure our latency percentiles, and ensure the operational defense layer remains stable under immense pressure.
The results validate our decoupled Next.js architecture, but they also highlight specific areas—namely dynamic product data and search queries—that require immediate optimization. This engineering journal breaks down the raw performance data, analyzes the critical user funnels, and outlines the strategic improvements necessary to push our P99 latency down to enterprise standards.
---

1. The Baseline: Achieving a Zero Percent Failure Rate

The Metrics:
During the sustained load test, the platform processed 35.29 requests per second. Over the duration of the test, the infrastructure handled 35,836 successful 2xx HTTP requests and 572 3xx redirects.
Most importantly, the test recorded:
  • 0.00% HTTP failures
  • 0.00% Unexpected statuses
  • 0 4xx (Client Errors)
  • 0 5xx (Server Errors / Timeouts)
  • 0 429 (Too Many Requests / Rate Limiting)
  • 0 403 (Forbidden)
The Architectural Reality:
Achieving a 0.00% failure rate under a sustained load of 35+ requests per second is a massive victory for a serverless Next.js deployment. In typical monolithic architectures, this level of concurrency often exhausts the MySQL or PostgreSQL database connection pools, leading to a cascade of 500 Internal Server Error or 504 Gateway Timeout responses.
The absence of 429 Too Many Requests indicates that our API routing and external data providers are not aggressively throttling our serverless functions. Furthermore, the lack of 5xx errors proves that our database connection management (likely utilizing a connection pooler like Prisma Accelerate or Supabase PgBouncer) is correctly queuing and resolving queries without dropping connections. The infrastructure is highly resilient.
---

2. Scenario Latency Breakdown

To understand exactly where the platform excels and where it struggles, we must isolate the latency by specific user scenarios.
ScenarioAvg LatencyP95 LatencyMax Latency
Homepage206 ms603 ms3609 ms
Search795 ms1116 ms4771 ms
Collection735 ms1124 ms4910 ms
Product973 ms1392 ms5692 ms
Account313 ms649 ms3669 ms
Cart164 ms442 ms2101 ms
Checkout160 ms455 ms2245 ms
Blog961 ms1348 ms2644 ms
Bespoke205 ms558 ms2280 ms
Admin195 ms496 ms2314 ms
Overall Global Metrics: Avg Latency: 639 ms | P95 Latency: 1203 ms
---

3. The Critical Funnel: Lightning Fast Cart & Checkout

The Metrics:
  • Cart: 164 ms (Avg) / 442 ms (P95)
  • Checkout: 160 ms (Avg) / 455 ms (P95)
The Architectural Reality:
In standard e-commerce platforms like WooCommerce or Magento, the cart and checkout routes are notoriously the slowest pages. This is because they must bypass static caching to dynamically calculate shipping rates, taxes, and real-time inventory levels.
For the Indrani platform to achieve a blazing-fast ~160ms average latency on the checkout flow is extraordinary. This suggests that the cart state is being expertly managed on the client side (via React Context or Zustand) and that the backend API routes handling the checkout initialization are highly optimized, likely running on Vercel Edge Functions rather than standard Node.js serverless runtimes.
This metric directly impacts top-line revenue. Every 100ms of latency reduced in the checkout flow corresponds to a measurable increase in conversion rates. By keeping the checkout under 200ms, the platform effectively eliminates friction-based cart abandonment.
---
The Metrics:
  • Search: 795 ms (Avg) / 1116 ms (P95)
  • Collection: 735 ms (Avg) / 1124 ms (P95)
  • Product: 973 ms (Avg) / 1392 ms (P95)
  • Blog: 961 ms (Avg) / 1348 ms (P95)
The Architectural Reality:
While the checkout flow is heavily optimized, the content and discovery phases of the application represent our primary performance bottleneck. The global P95 latency is 1203 ms, and this is almost entirely driven by the Product and Search scenarios.
A nearly 1-second average latency for loading a Product page (973 ms) indicates that the route is relying heavily on Server-Side Rendering (SSR) rather than Static Site Generation (SSG) or Incremental Static Regeneration (ISR). When a user requests a product, the server is actively querying the database for variants, real-time inventory, related products, and metadata before compiling the HTML and sending it to the browser.
Similarly, the Search function (795 ms) is executing complex database queries—likely utilizing SQL LIKE operators or heavy full-text search indexing—that consume significant compute time.
The Technical Solution:
To resolve this, we must shift these workloads to the edge network.
  1. Implement ISR for Products: Product pages should utilize Next.js revalidate tags. The HTML should be cached globally at the edge and revalidated in the background only when inventory or pricing actually changes. This will drop the 973ms latency to match the Homepage (206ms).
  2. Decouple Search: Move the search logic away from direct database queries and integrate a dedicated search index like Algolia, Typesense, or Meilisearch, which can return sub-50ms results.
---

5. Securing the Operational Defense Layer: Admin & Bespoke

The Metrics:
  • Admin: 195 ms (Avg) / 496 ms (P95)
  • Bespoke: 205 ms (Avg) / 558 ms (P95)
  • Account: 313 ms (Avg) / 649 ms (P95)
The Architectural Reality:
The Indrani Jewelers platform is more than just a storefront; it operates as a sophisticated operational defense layer for the business, handling inventory tracking, custom bespoke orders, and administrative tasks.
It is highly encouraging to see that the Admin and Bespoke scenarios maintained average latencies of roughly 200 ms during a heavy stress test. This means that even while the public storefront was being hammered with 35 requests per second, the internal operational tools remained highly responsive for the staff. The backend architecture successfully isolates standard e-commerce traffic from internal administrative queries, ensuring that sudden traffic spikes do not paralyze the business's day-to-day operations.
---

6. Understanding Maximum Latency Spikes (Cold Starts)

If we look at the Max Latency column, we see significant spikes:
  • Product Max: 5692 ms
  • Collection Max: 4910 ms
  • Search Max: 4771 ms
These 4 to 5-second maximums are the classic signature of Serverless Cold Starts. When the stress test initiates, Vercel must suddenly provision dozens of new serverless function instances to handle the immediate influx of concurrent traffic. The very first request hitting a newly spun-up instance must wait for the Node.js runtime to boot, the framework to initialize, and the database connection to be established.
Once the functions are "warm," the latency drops back down to the averages (700-900ms). While we cannot entirely eliminate cold starts in a serverless environment, we can mitigate their impact by reducing the overall bundle size of our API routes, utilizing Edge Runtimes where possible, and keeping database connections open via a dedicated connection pooler.
---

7. Next Steps: Engineering for Scale

The Indrani Jewelers stress test proves that the foundational architecture is highly resilient, secure, and capable of handling significant traffic without dropping a single request. However, to transition from a "stable" platform to an "elite" platform, the engineering team must address the P95 latencies.
Action Plan:
  1. Aggressive Cache Strategies: Transition the /product/[slug], /collection/[slug], and /blog/[slug] routes to utilize Next.js Incremental Static Regeneration (ISR). We must stop querying the database on every single page load.
  2. Streaming React Server Components: For dynamic data that cannot be cached (like personalized recommendations on a product page), implement React Suspense boundaries. Send the static HTML layout instantly, and stream the heavy database queries in the background.
  3. Search Indexing: Offload the /search endpoint to a dedicated, memory-based search engine to prevent heavy analytical queries from slowing down the primary transactional database.
By implementing these three architectural shifts, we project that the global P95 latency will drop from 1203 ms to under 400 ms, establishing Indrani Jewelers as a premier, high-performance digital storefront.
---

💡 Key Engineering Takeaways

Decoupled edge architectures can successfully handle high concurrency with a 0.00% failure rate. Dynamic routing and database-heavy endpoints (like Search and Product pages) form the primary latency bottlenecks. Sub-200ms Cart and Checkout latencies directly translate to higher conversion rates and reduced abandonment.

Frequently Asked Questions

What does a 0.00% HTTP failure rate actually mean during a stress test?

It means that out of over 35,000 automated requests fired at the server, not a single one was dropped, timed out, or resulted in a server crash. The hosting infrastructure successfully caught, processed, and returned data for every single incoming connection, proving the architecture is highly stable.

Why is the Product page latency significantly higher than the Checkout latency?

In this specific architecture, the checkout is highly optimized—likely processing quickly on the client-side or utilizing fast edge functions. The product page, however, is likely Server-Side Rendered (SSR). It takes time (average 973ms) for the server to query the database for product details, images, variants, and stock levels before generating the page.

What is P95 latency and why does it matter more than the average?

P95 latency means that 95% of all requests were completed in that time or faster. While an average can be skewed by a few incredibly fast requests, the P95 metric gives a much more realistic picture of what the vast majority of your actual human users are experiencing during heavy traffic.

How can we fix the 5-second maximum latency spikes?

Those massive spikes are caused by "serverless cold starts"—the time it takes for the hosting provider to boot up a brand new server instance to handle a sudden surge in traffic. You can reduce this by optimizing your backend bundle size, using Vercel's Edge network, or utilizing Incremental Static Regeneration (ISR) to serve cached files instead of booting functions.

Is 35 requests per second considered high traffic?

Yes. While it may not sound massive, 35 requests per second equates to roughly 3 million requests per day. For a customized e-commerce platform processing dynamic transactions, inventory checks, and search queries, handling this without a single dropped connection is an excellent baseline performance metric.

Feedback

Was this article helpful?

Related Engineering Diaries