Gunjan Sharma

Engineering

I Sped Up a SaaS App by 8x. Then Nearly Destroyed It.

I sped up a friend's successful B2B SaaS startup by 8x with a single line of configuration.

One week later, I nearly destroyed his business.

His Next.js application was running on an EC2 instance using PM2 in fork mode. I wanted to be the hero, so I changed it to cluster mode and spun up 8 instances.

The site flew. My friend thought I was a performance god.

Then the customer tickets started rolling in: "The site loads, but then it just infinitely reloads forever."

We panicked. We blamed the codebase. We audited the middleware. We rewrote the cookie logic. We deployed 30+ different hotfixes while the customers were screaming.

Nothing worked. We were completely exhausted.

Finally, I reverted PM2 back to fork mode. The infinite reloading stopped instantly.

Here is the anatomy of a configuration disaster:

Next.js generates specific asset chunks during builds and rollouts. By forcing PM2 into cluster mode, I created a schizophrenic server. Process 1 would serve the initial HTML, but the subsequent client-side request would hit Process 2, which had a mismatched chunk version.

The browser panicked, threw an Asset Version Mismatch, and constantly reloaded to fix it.

I didn't scale the application. I just distributed the failure.

The Hard Truth: Never apply a "quick fix" to a live system without understanding the underlying physics of the framework.

If an optimization takes 10 seconds to apply, it will take 10 days to debug.

If you need to scale, scale at the Load Balancer. Stop playing God with the process manager.

I Sped Up a SaaS App by 8x. Then Nearly Destroyed It. | Gunjan Sharma