A web application that works perfectly for 1,000 users can slow to a crawl at 100,000. Scaling is the work of keeping response times low and the system reliable as traffic, data and features grow, without costs growing out of control. This guide covers the best practices for scaling web applications: how to find bottlenecks, the difference between vertical and horizontal scaling, and the techniques (caching, database optimisation, queues, CDNs and autoscaling) that experienced teams use at each stage of growth.
What does scalability mean for a web application?
A scalable web application can handle more users, requests or data by adding resources, while keeping performance and reliability acceptable. Three things usually need to scale:
- Traffic: more concurrent users and requests per second.
- Data: larger databases, more files and more history.
- Teams and features: more developers shipping changes without breaking each other’s work.
Scalability is different from raw performance. A fast app on one server is not scalable if the only way to grow is to buy an ever-larger server.
Vertical vs horizontal scaling
| Vertical scaling (scale up) | Horizontal scaling (scale out) | |
|---|---|---|
| How | Bigger server: more CPU, RAM, faster disks | More servers behind a load balancer |
| Effort | Easy, often no code changes | Requires stateless application design |
| Limit | Hardware ceiling and rising cost | Practically unlimited for the app tier |
| Resilience | One server is a single point of failure | Survives the loss of individual servers |
| Best for | Early stage, databases, quick wins | Growing traffic and high availability |
Most systems use both: scale the application tier horizontally and scale the database vertically first, then with replicas.
Start by measuring, not guessing
Before changing architecture, find out where time is actually spent:
- Application performance monitoring (APM) shows slow endpoints, database queries and external calls.
- Load testing with tools such as k6, JMeter or Locust shows where the system breaks and how many users it can serve.
- Key metrics: response time percentiles (p95 and p99, not just averages), error rate, throughput, CPU, memory and database load.
In most web applications the first bottleneck is the database, followed by slow external API calls and unoptimised code paths.
Best practices for scaling web applications
1. Make the application tier stateless
Store sessions in Redis or a database, and uploaded files in object storage such as Amazon S3, instead of on the web server’s disk. Any server can then handle any request, which is the foundation of horizontal scaling.
Free resource
Upgrade and patching checklist
Want this applied to your project? Our engineers will send it with notes for your stack.
2. Put a load balancer in front
A load balancer (for example AWS Application Load Balancer, NGINX or HAProxy) spreads requests across servers, removes unhealthy servers automatically and enables zero-downtime deployments.
3. Cache aggressively at every layer
- Browser and CDN caching for static assets and public pages.
- Application caching in Redis or Memcached for expensive queries, computed results and API responses.
- Database query caching and materialised views for heavy reports.
Define clear expiry and invalidation rules: stale data is the main risk of caching.
4. Optimise the database
- Add the right indexes and review slow-query logs regularly.
- Eliminate N+1 queries by loading related data in batches.
- Use connection pooling so the database is not overwhelmed by connections.
- Add read replicas to offload read-heavy traffic.
- Archive or partition large historical tables.
- Consider sharding only when a single database can no longer cope, because it adds significant complexity.
5. Move slow work to background queues
Emails, report generation, image and video processing, imports and third-party API calls should run in background workers (for example Laravel Queues with Redis, Sidekiq, Celery or Amazon SQS). Users get an instant response, and you can scale workers separately from web servers.
6. Use a CDN
A content delivery network serves images, scripts, styles and even cached pages from locations close to users, reducing latency worldwide and taking load off your servers. It also absorbs traffic spikes and some attacks.
7. Autoscale and use the cloud well
Configure autoscaling groups, Kubernetes Horizontal Pod Autoscalers or serverless functions to add capacity during peaks and remove it afterwards. Set limits and budgets so a bug or attack cannot create runaway costs.
8. Design APIs for scale
Paginate large results, support filtering, apply rate limits per client and return only the data clients need. Use idempotency keys for operations such as payments so retries are safe.
9. Break up the monolith only when needed
A well-structured modular monolith scales further than many teams expect. Extract services when a specific part has very different scaling needs (for example search, media processing or real-time messaging) or when separate teams need independent deployments. Microservices add network, deployment and monitoring complexity.
10. Build in resilience
- Timeouts, retries with backoff and circuit breakers for external services.
- Graceful degradation: if recommendations fail, still show the page.
- Health checks, multiple availability zones and tested backups and restores.
11. Automate deployments and infrastructure
Infrastructure as code (Terraform, CloudFormation), CI/CD pipelines and containerisation make it safe to add servers, environments and regions quickly and repeatably.
12. Monitor continuously
Centralised logs, metrics, tracing and alerts on user-facing symptoms (latency and errors) let you spot problems before users report them and plan capacity ahead of growth.
A practical scaling roadmap
| Stage | Typical traffic | Focus |
|---|---|---|
| Launch | Hundreds of users | One well-configured server, managed database, backups, monitoring |
| Growth | Thousands of users | CDN, Redis caching, queues, query optimisation, vertical database scaling |
| Scale | Tens of thousands of users | Load balancer, multiple stateless app servers, read replicas, autoscaling |
| High scale | Hundreds of thousands and more | Service extraction where justified, multi-region, advanced data partitioning |
Move to the next stage when measurements show you need to, not in advance.
Common scaling mistakes
- Adding servers without fixing slow database queries.
- Storing sessions or files on local disk, which breaks horizontal scaling.
- Moving to microservices too early.
- Caching without an invalidation strategy.
- No load testing before marketing campaigns or seasonal peaks.
- Ignoring cost: scaling that is technically successful but financially unsustainable.
Frequently asked questions
What is the best way to scale a web application? Measure first, then make the application stateless, add caching and a CDN, optimise the database, move slow work to queues and scale the app tier horizontally behind a load balancer.
What is the difference between scalability and performance? Performance is how fast the system is under a given load; scalability is how well it maintains that performance as load grows.
When should I move from a monolith to microservices? When parts of the system have very different scaling needs or separate teams need independent deployments. Many applications scale well as a modular monolith.
Which databases scale best for web apps? PostgreSQL and MySQL scale very well with indexing, replicas and caching. NoSQL databases help for specific patterns such as very high write volumes or flexible schemas.
Need help scaling your application?
Vibidsoft audits and scales web applications: performance profiling, database optimisation, caching, queues and cloud architecture on AWS, Azure and Google Cloud. See our cloud and DevOps services and backend development, or contact us for a scalability review.
