The order things break
Unindexed queries → N+1 patterns → no caching → single server limits → database write capacity. Fix them in that order, and only when you have measured the problem. Most applications never get past step three.
Scaling advice online is written by companies operating at a size almost no Indian business reaches. Applied prematurely, it makes your system slower to build, more expensive to run, and harder to debug — while solving a problem you do not have.
Stage by stage: what actually changes
| Scale | What you need | Rough infra cost |
|---|---|---|
| Up to ~1,000 users | One decent server. Nothing clever. | ₹1,000 – ₹4,000/mo |
| ~10,000 users | Indexes, caching, CDN | ₹4,000 – ₹15,000/mo |
| ~50,000 users | Separate DB server, Redis, background jobs | ₹15,000 – ₹60,000/mo |
| ~100,000+ | Load balancing, read replicas, autoscaling | ₹60,000+/mo |
Perspective worth keeping: a single modest server running well-written code comfortably serves thousands of concurrent users. If your application struggles at a few hundred, the problem is almost never the server size — it is the queries.
Fix these first, in this order
1. Add the missing indexes
The single highest-return fix in web application performance. A query filtering on an unindexed column forces the database to scan every row. At a thousand rows nobody notices; at a million the application falls over.
How to find them: enable your database's slow query log for a day. The offenders will be obvious, and adding an index usually turns a two-second query into a two-millisecond one.
2. Eliminate N+1 queries
Fetch fifty orders, then loop and query the customer for each one — that is fifty-one queries where two would do. Extremely common in ORM-based code and invisible until traffic rises.
How to find them: log query counts per request. Any page issuing dozens of queries is doing this.
3. Cache what does not change often
- Expensive computed results — dashboards, reports, aggregate counts
- Rendered fragments that are identical for all users
- Reference data — categories, settings, product lists
- Static assets, via a CDN with long cache lifetimes
Redis handles the first three. A CDN handles the last, and for an India-focused audience it also solves latency.
4. Move slow work out of the request
Sending email, generating PDFs, processing images, and calling third-party APIs should not happen while a user waits. Push them to a background queue and respond immediately.
Users do not experience your server's capacity. They experience how long they wait — which is usually dominated by work that never needed to happen synchronously.
5. Only now, add servers
Once queries are indexed, N+1 is gone, caching is in place, and slow work is asynchronous, adding capacity is straightforward: a load balancer in front of two or more application servers, with sessions stored in Redis rather than on individual servers.
The database is the hard part
Application servers scale horizontally with little difficulty. Databases do not, which is why they should be protected:
- Read replicas Send reporting and read-heavy queries to a replica, keeping the primary for writes. Handles the majority of read scaling problems.
- Connection pooling Databases have hard connection limits. A pooler prevents your application from exhausting them under load.
- Archive old data Move records nobody queries into an archive table. Smaller working sets mean faster queries.
- Partition large tables Usually by date. Effective for logs, transactions, and events.
- Sharding Splitting data across multiple databases. Powerful, complex, and genuinely a last resort.
Before optimising anything, measure. Engineering intuition about bottlenecks is frequently wrong. Without application performance monitoring you will spend weeks optimising something that was never the constraint, while the actual bottleneck remains untouched.
Planning for a traffic spike
Sale days, campaigns, and press coverage are predictable events. Preparation is straightforward:
- Load-test beforehand with realistic traffic patterns — not just a homepage hammer.
- Increase server capacity a day early, not during the spike.
- Cache aggressively for the duration, even if data is slightly stale.
- Have a degraded mode — disable non-essential features rather than failing entirely.
- Watch dashboards live rather than reading about it afterwards.
- Know in advance which single change buys you the most headroom.
What not to do
- Do not adopt microservices to scale. They solve team-coordination problems, not traffic problems, and cost heavily in operational complexity.
- Do not add Kubernetes early. It is powerful and it will consume your engineering attention.
- Do not shard prematurely. Almost nothing at Indian SMB scale needs it.
- Do not optimise without profiling. You will guess wrong.
Application slowing down under load and unsure why? Tell us what you are seeing — the cause is usually identifiable quickly. See also our database guide and hosting guide.