Make it possible to run more copies of the app, then let the hosting add copies when traffic grows. That needs three things: the app keeps nothing important in its own memory or disk (sessions, uploads and data live in shared services such as a managed database and file storage), every setting comes from configuration rather than code, and the hosting can add capacity through a setting. Then scaling is a change in a dashboard, not a rewrite.
What's the problem
It works for you and a few testers. You're about to launch, or traffic is growing, and you don't know what happens at a thousand users. Or you already know: it slows down, errors pile up, and it falls over at the worst moment.
Why it happens
- One machine can only get so big. Making the server bigger (vertical scaling) works until it doesn't. Beyond that, the app has to run as several copies (horizontal scaling).
- State gets in the way. If the app keeps logins, uploaded files or job queues in its own memory or local disk, a second copy can't see them, so adding copies breaks things.
- The database becomes the bottleneck. More app copies mean more queries and connections. A database that's slow or undersized limits everything.
- Capacity is hard-coded. Fixed server sizes, single instances, settings in code. Growing means changing code and redeploying under pressure.
How to fix it
- Move state out of the app. Sessions in a shared store or signed cookies, uploads in object storage, data in a managed database, background jobs in a queue.
- Put every setting in configuration, so new copies start identically.
- Run at least two copies behind a load balancer, even before you need to. It proves the app works that way, and survives one copy failing.
- Use hosting that can add copies, automatically or through a setting.
- Fix the database first: indexes, connection pooling, and a managed service you can resize. See my database is slowing everything down.
- Load-test before launch at a few times your expected traffic, and watch what fails first.
- Add monitoring, so you see limits approaching before users do.
When to call Preventionlabs
This is one of the three things every resurrection delivers: infrastructure where capacity can be increased through configuration, without changes to the app's code, demonstrated before handover. It doesn't mean unlimited capacity at a fixed cost (hosting costs stay yours and grow with use), but it means that when users arrive, you scale up without rebuilding. The free assessment tells you what your app needs to get there.
Submit your project for a free assessmentFree assessment. $10,000 AUD flat to get it live, only if we take it on and you go ahead.
Sources
- The Twelve-Factor App: VI. Processesengineering methodology
Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.
- The Twelve-Factor App: VIII. Concurrencyengineering methodology
But an individual VM can only grow so large (vertical scale), so the application must also be able to span multiple processes running on multiple physical machines.
- Replit: Publishing: deployment typesplatform docs
Autoscale Deployment Automatically adjusts resources based on your app’s usage.
- Preventionlabs: Terms of Service, section 5our terms of service
Infrastructure is scalable: capacity can be increased through configuration, without changes to the app's code.