Your app worked well with your team and the first users. One day a campaign arrives, twenty people come in at once and it goes down. There is almost always an explanation, and it can be fixed.
What usually fails
- Database connection limits. Each user opens connections and they run out. You have to control how many get opened and close the ones that are not used.
- Heavy work in the same request. If generating a report or sending an email blocks the user, a few people at once saturate the server.
- A single process handling everything. Without several processes or instances, one slow request holds up the others.
- Free or minimal plans. They have limits on CPU, memory or requests per minute, and some services “sleep” when they are not used.
- Uncontrolled external services. Calls to third-party APIs with no maximum time, no retries and no queues.
- State stored in memory. Sessions or temporary data that get lost or go out of sync when there is more than one instance.
How to check before it happens
A load test simulates real users on your app in a controlled way. With a tool like k6 you can simulate dozens or hundreds of users and see at what point errors or high response times appear.
What gets fixed, in order
- Find the bottleneck with the load test.
- Move heavy work to queues.
- Add cache and tune the queries.
- Configure the number of processes and connections.
- Increase the server size only when the above is already solved.
Leave the load test ready to repeat every time you launch something big. That way you find the problems and not your customers.
If your app goes down as it grows, see how I take projects to production.