Scaling a web application from 100 to 100,000 users

In short: Scaling a web application means fixing bottlenecks in the order they actually appear. Usually the database comes first: missing indexes, inefficient queries, too many connections. Then come caching, a CDN for static content, several application instances behind a load balancer and background jobs for slow tasks. A well-built monolith on a solid database carries many applications well past a hundred thousand users without needing microservices.

Measure first, then scale

Scaling without measurement is guesswork. Before adding infrastructure, you need answers to simple questions. Which requests are slow? Where does the server spend its time? How busy are CPU, memory and database? Application performance monitoring, structured logs and metrics tell you. Our post on monitoring and observability explains how to set that up.

It also matters what "users" means for your application. A hundred thousand registered accounts that log in once a month are a very different load from a few thousand concurrent users writing data all the time. Plan for concurrent load and requests per second, not account numbers.

The typical stages of scaling

One server, one database

At the start, most applications are fine with one application server and a managed database, for example PostgreSQL from a cloud provider. It is simple to run and cheap. At this stage a clean data model matters more than any infrastructure. Our database selection guide compares the options.

Taking load off the database

The first real bottleneck is almost always the database. Typical causes are missing indexes, N+1 queries from the ORM and queries that load more data than needed. EXPLAIN ANALYZE in PostgreSQL finds slow queries quickly. A connection pooler like PgBouncer stops many application instances from overwhelming the database with connections. As load grows further, read replicas take over part of the read traffic.

Caching and CDN

Static files like images, JavaScript and CSS belong on a CDN that serves them close to the user. For dynamic data that rarely changes, a cache such as Redis or Valkey pays off. Pages that look the same for every visitor can be pre-rendered or cached briefly. Every cache raises the question of when it becomes stale, though, so start with a few clearly defined places.

Scaling the application horizontally

When one server is no longer enough, run several instances behind a load balancer. The prerequisite is a stateless application: sessions live in the database or Redis, uploaded files in object storage, not on the local disk. Containers and platforms with autoscaling make this step comparatively easy. A CI/CD pipeline makes sure every instance runs the same version. Our practical guide to CI/CD pipelines shows how to build one.

Background jobs and queues

Sending emails, generating PDFs, processing images, importing data: these tasks do not belong in the user's request. A queue with its own worker processes takes them and works through them in the background. The application stays responsive and load spikes get absorbed.

When microservices start to make sense

Microservices mainly solve organisational problems: several teams need to develop and deploy independently. For a small team they usually add more work than they save, because network communication, distributed debugging and data consistency come on top. A modular monolith can be split later where one part genuinely has different requirements. We weigh this up in detail in microservices vs. monolith.

Common mistakes

The most common mistake is building too early for load that does not exist yet. Complex infrastructure costs money and development time that the product then lacks. The opposite is just as dangerous: nobody watches the metrics until the application falls over during the first marketing campaign. Load tests before predictable peaks and alerts on rising response times prevent these surprises.

Frequently asked questions (FAQ)

When do I need to start worrying about scaling?

When your measurements show response times rising or resources running short. Until then, a clean data model, monitoring and an architecture that allows horizontal scaling later are enough. Doing more up front rarely pays off.

Do I need Kubernetes for a scalable application?

Not necessarily. Many applications run well on managed container platforms or PaaS offerings that scale automatically. Kubernetes makes more sense when you run many services and have a team that can maintain the platform.

What does scaling in the cloud cost?

That depends heavily on architecture and usage patterns. The biggest cost drivers are often oversized servers, unnecessarily large databases and data transfer. Reviewing costs regularly and scaling automatically with demand keeps the bill under control.

Can I host my application in Germany and still scale?

Yes. German and European cloud providers offer managed databases, containers and load balancers, and the large providers have data centres in Germany. For most applications, server location is no obstacle to growth.

Conclusion

Scaling is a sequence of small, measured steps: optimise the database, cache, scale horizontally, move work to the background. If you take each step only when the data calls for it, you grow on infrastructure you understand and can afford. If you want to prepare your web application for growth, talk to us about web development and architecture.