The day your app gets shared

You spend weeks building something, show it to a few people, and then one morning someone posts it to a forum or newsletter with a hundred thousand readers. By the time you see the notification, your server is already struggling.

This is a good problem to have. It is also an avoidable disaster. The apps that survive it are not necessarily better built than the ones that fall over. They are just hosted differently.

Why traffic spikes are different from steady growth

If your app grows steadily, you have time to notice and adjust. You see the numbers climbing over days or weeks and can make decisions at a reasonable pace.

A spike is different. You go from fifty visitors an hour to five thousand in the space of a few minutes. A server that was handling your normal load fine suddenly has fifty times as many requests queued up. Most of them start timing out. Visitors see errors. Some try to refresh, which makes things worse. The moment passes, and the story people tell about your app is that it broke.

The fixed-size server problem

Traditional hosting gives you a machine with a fixed amount of memory and CPU. You pay for it whether you use it or not, and when demand exceeds its capacity, it falls over. The usual advice is to pick a server big enough for your expected peak. But peaks are unpredictable, and paying for capacity you rarely use is wasteful.

The alternative is running multiple smaller instances and adding more of them when load increases. This is what the large platforms do, and it works well. The challenge is that "add more instances" is not instant. Spinning up a new server, loading your app, and making it ready to serve traffic takes time. If the spike is steep enough, you might need capacity before you can provision it.

What Prodwise watches

We track a few things continuously for every app we host. Request rate is the obvious one: how many visitors are arriving per second. But request rate alone does not tell you whether the app is coping. A slow app might be processing every request, just slowly.

So we also watch response times. When the median response time for a page that normally takes 80ms starts climbing past 300ms, that is a signal. When error rates start rising alongside it, that is confirmation. We start scaling before the app tips into failure rather than after.

We also keep a small amount of capacity warm. Rather than scaling from zero when demand spikes, there is always a baseline ready to absorb sudden increases while new instances come online.

The parts that are harder than they look

Scaling the web layer is the easy part. Most modern apps connect to a database, and databases do not scale the same way. Every new instance of your app opens its own connections to the database, and databases have a finite number of connections they can handle. Scale your app ten times and you have ten times as many database connections.

This is something we account for when provisioning apps. Connection pooling sits between your app and its database, so spinning up ten instances does not mean ten times the connection load. It is one of those things you would not necessarily think about until it became a problem at the worst possible moment.

After the spike

Traffic spikes are typically short. The newsletter goes out, readers click, and within an hour or two you are back to normal levels. Prodwise scales back down after the load subsides, so you are not paying for the extra capacity once it is no longer needed.

The outcome you want is simple: the thousandth visitor to arrive during the spike has the same experience as the first. They see a fast page, not a timeout. And the story people tell is about the product, not the outage.

Automatic scaling is included on the Pro plan. The Hobby tier runs on shared infrastructure that handles moderate spikes but is not designed for sudden large peaks.