Scale a Frappe/ERPNext Multi-Tenant Deployment for Traffic Spikes (HAProxy + Database Tuning)

We run a multi-tenant school management platform built on Frappe/ERPNext, serving several schools from a single deployment. Our infrastructure is spread across five dedicated servers — application, API, database, Redis, and background workers — on a bare-VPS provider. There are no managed cloud services and no autoscaling available to us. Everything is self-hosted and must remain so. The problem Our traffic is spiky by nature. When a school sends a notification, a large number of parents open the app within the same few minutes. We need the platform to stay responsive through those bursts, with a target of approximately 1,500 concurrent users at peak. We are not confident the stack can currently handle that, and we know parts of it are running on default configuration that was never tuned for production load. Scope of work 1. Audit and baseline — first deliverable • Review the current architecture across all five servers • Load-test the existing setup to establish a real baseline — we want measured numbers, not estimates • • Identify the actual bottlenecks in priority order Deliver a short written findings report before any implementation begins We want to know what is genuinely limiting us before anything is rebuilt. Applicants who propose implementation without measuring first will not be considered. 2. Database layer Our MariaDB instance runs on stock defaults despite substantial RAM being available, and the connection limit is low enough that adding application capacity would exhaust it. This must be addressed before any horizontal scaling. • • • • Tune buffer pool, connection limits, and thread handling for the available hardware Evaluate and implement connection pooling where appropriate Advise on read replica viability for our workload Identify and address the slowest queries under load 11 / 16 Confidential — Internal Review 3. Load balancing and horizontal scaling • Deploy HAProxy — or nginx, if you propose and justify it — as a self-hosted load balancer • Health checks with automatic removal and re-entry of unhealthy backends • Sticky sessions where the application requires them • Correct handling of WebSocket connections; we use Socket.IO for real-time features and this must not break • Graceful connection draining for zero-downtime deployments • Configuration must be reproducible and documented, not hand-edited on the server 4. Application layer • Right-size worker counts against actual CPU and memory rather than guesswork • Resolve inconsistencies in our nginx and process-manager configuration — there is leftover config from a previous migration that needs untangling • Caching strategy for the notification-spike scenario specifically, where many users request similar content simultaneously • Static asset and CDN strategy 5. Observability • Monitoring across all five servers, with dashboards our team can actually read • Alerting that fires before problems become outages • A documented runbook for our team 6. Validation • Load test to the 1,500 concurrent target and demonstrate the result • Document measured capacity limits and the failure mode when exceeded • Handover documentation and a walkthrough session Required experience • Frappe/ERPNext production deployments. This is essential, not a nice-to-have. The framework has specific requirements around multi-tenancy, background workers, and Socket.IO that generic DevOps experience does not cover. • HAProxy or nginx as a load balancer, in production, at scale • MariaDB/MySQL performance tuning with demonstrable before-and-after results • Load testing with k6, Locust, JMeter, or similar • Bare-VPS infrastructure work without managed cloud services • Infrastructure-as-code (Ansible or Terraform). We do not want changes that exist only in one person's shell history.