Design for the spike you can predict
Most Indian consumer businesses do not have uniform load. They have campaign launches, salary week, admission season, festival offers and IVR-driven call bursts. Capacity planned on monthly averages fails on exactly the days that matter commercially.
We size and test against the known peak, not the mean, and we make the peak explicit in the requirements document.
Patterns that hold under load
None of these are exotic. Skipping them is what causes most incidents.
- Queue anything that is not needed in the response: notifications, exports, third-party syncs
- Idempotency keys on every write endpoint that a client may retry
- Connection pooling with hard limits, so a traffic spike cannot exhaust the database
- Read replicas for reporting so analytics never contend with transactions
- Circuit breakers around third-party APIs such as payment, SMS and IVR providers
- Structured logging with a request ID that survives across services
The database is usually the ceiling
Node.js services scale horizontally easily; PostgreSQL does not. Long-running report queries executed against the primary are the most common cause of a slow application that looks like a code problem.
Move reporting to replicas, add covering indexes for the three or four queries that dominate traffic, and paginate everything that a user can filter.
Prove it before launch
A load test at twice the expected peak, run against a production-shaped dataset, takes a day and prevents the launch-week incident that costs a week. Record the numbers and re-run them before every major release.
Planning something similar for your organisation?
Talk to the InfozIT team about your CRM, HRMS, ERP, product or engineering requirement.