Website Scaling: When Load Grows

A website starts to slow down at 500 RPS, and the server hits CPU limits — it's time to scale. Many clients come with the problem: "We bought a powerful server, but the load didn't drop." We've encountered this many times. Scaling infrastructure is not about replacing a small server with a big one. It's an architectural process: first optimization, then horizontal scaling, then vertical (if needed). The wrong order leads to wasted budget without solving the problem. Our engineers with ten years of experience help navigate this path without downtime. We guarantee stability at every stage — all changes go through a stage environment, ensuring 99.9% uptime. One client — an online store with 2000 RPS traffic — after architecture reorganization reduced infrastructure costs by 40% while doubling the load. Budget savings amounted to up to 40% of previous expenses.

How to Diagnose Bottlenecks

Before scaling, understand where the bottleneck is. We use standard Linux utilities:

# CPU, I/O, memory, database, network diagnostics top -b -n 1 | head -20 iostat -x 1 5 free -m && vmstat 1 5 mysql -e "SHOW PROCESSLIST;" psql -c "SELECT pid, now()-pg_stat_activity.query_start AS duration, query FROM pg_stat_activity WHERE state != 'idle' ORDER BY duration DESC LIMIT 10;" ss -s # Load testing with k6, ab, wrk k6 run --vus 100 --duration 30s script.js ab -n 10000 -c 100 https://mysite.com/ wrk -t12 -c400 -d30s https://mysite.com/ 

According to Wikipedia, horizontal scaling is often more cost-effective for high-load systems.

Why Caching is the First Step

Caching provides the fastest ROI. One project — an online store on Laravel — after setting up Redis and Nginx fastcgi_cache reduced database load by 80% at the same RPS. Here's the configuration:

# Nginx: static caching and FastCGI cache for PHP location ~*\.(css|js|jpg|png|gif|ico|woff2)$ { expires 1y; add_header Cache-Control "public, immutable"; } fastcgi_cache_path /tmp/nginx-cache levels=1:2 keys_zone=MYAPP:100m inactive=60m; fastcgi_cache_key "$scheme$request_method$host$request_uri"; 

Redis additionally caches application data: php artisan config:cache, route:cache, view:cache.

CDN and Load Balancing

CDN (Cloudflare, CloudFront) offloads the server from static content. We configure a rule: static content is cached at the Edge, API is passed through. This requires setting Cache-Control headers in code: const cacheControl = isStatic ? 'public, max-age=31536000' : 'no-cache';. A load balancer (Nginx, HAProxy) distributes traffic among application replicas — essential for horizontal scaling.

Vertical vs Horizontal Scaling: Which is Better?

Horizontal scaling (adding replicas) is 3–5 times more effective than vertical scaling (upgrading hardware) under high load because it distributes traffic and provides fault tolerance. Vertical scaling is simpler initially but runs into physical limits.

Database Optimization

Even with caching, the database is often a bottleneck. We find slow queries via EXPLAIN ANALYZE and add indexes:

EXPLAIN ANALYZE SELECT * FROM products WHERE category_id = 5 ORDER BY created_at DESC LIMIT 20; CREATE INDEX CONCURRENTLY idx_products_category_created ON products (category_id, created_at DESC); 

Connection pooling using PgBouncer reduces database load by 2–3 times. We also configure connection pools for applications: pdo_mysql.default_socket and max_connections in the MySQL config.

How Task Queues Work

Heavy operations — email sending, PDF generation, image processing — should not be executed synchronously. We use queues: Laravel Queue + Redis, RQ, or RabbitMQ. This offloads the web server and improves responsiveness. Example with Laravel:

dispatch(new ProcessImageJob($file)); // The frontend does not wait for completion — the user gets an instant response 

[program:queue-worker] process_name=%(program_name)s_%(process_num)02d command=php /var/www/artisan queue:work redis --sleep=3 --tries=3 numprocs=2 autostart=true autorestart=true user=www-data 

Horizontal Scaling with Kubernetes

When one server is not enough, add replicas. Kubernetes with HorizontalPodAutoscaler automatically scales the number of pods based on CPU:

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: myapp-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: myapp minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 

Service Separation and Queues

Gradually split the monolith into microservices:

• API Gateway (Nginx/Kong)
• Auth Service (stateless JWT)
• Content Service
• Media Service (separate for file uploads)
• Search Service (Elasticsearch)

Heavy operations are moved to queues: instead of synchronous processing, we use Laravel Queue + Redis, executing dispatch(new ProcessImageJob(...)).

Architecture by Load Level

Rule: scale what has been measured as a bottleneck. Don't scale assumptions.

What's Included in the Work

1. Audit of current architecture and bottlenecks (1-2 days)
2. Setup of caching and CDN
3. Database optimization: indexes, configs, pooling
4. Application containerization and orchestration setup
5. Load testing before and after changes
6. Documentation and instructions for the team

Timeline and Budget

Audit and optimization under load (without changing architecture) — 1-2 weeks. Migration to horizontal scaling — 2-6 weeks. The cost is calculated individually after assessing your system, but optimization savings usually amount to 30-50% of current costs. Get a consultation — our certified engineers will analyze your infrastructure and propose a plan. Order an infrastructure audit — we will identify bottlenecks and develop a scaling plan.

Experience with over 50 scaling projects, stability guarantee — all changes go through a stage environment.