A UK SaaS platform was losing users because the API couldn't keep up with growth.
When user traction outpaces backend architecture, founders often face a tough choice: endure the churn, or pause feature development for a costly 6-month rewrite. We found a third path.
Act I: The Ascent
Everything was going perfectly. The startup had hit a milestone most founders only dream of: 5,000 concurrent active users. The marketing campaigns were converting, the sales team was closing deals, and the product was genuinely loved by the market. But behind the scenes, the foundation was starting to crack. Success was quietly becoming a liability.
Act II: The Breaking Point
As traffic surged, the platform began to buckle under its own weight. P95 API latency crept above 800ms. Checkout flows were silently timing out, leaving revenue on the table. Customer support tickets had doubled in just three weeks.
The engineering team, operating in panic mode, had tried scaling vertically by throwing more expensive hardware at the problem and adding a heavy caching layer. Neither solved the root cause. Growth was now actively hurting the business. The system architecture looked something like this chaotic mess:
Act III: Diagnosing the Truth
Before writing a single line of code, we stepped back and instrumented the critical paths. Rather than guessing, we let the telemetry tell the story. The problem wasn't a monolithic architecture that needed to be split into a complex web of microservices. It was simpler, yet more dangerous: a few poorly structured queries were locking the database, and synchronous file processing was completely blocking the main API threads.
Act IV: The Intervention
We executed a three-week surgical intervention—refactoring the engine while the car was still driving down the highway at 100mph:
- Database Schema Overhaul: We refactored the two hottest tables, introducing composite indexes that matched their access patterns. This immediately turned 2-second analytics queries into sub-50ms lookups.
- Asynchronous Queues: We migrated all heavy, non-critical operations (like report generation and email dispatching) off the API request lifecycle and into a BullMQ background job queue.
- N+1 Query Elimination: We rewrote the ORM data-fetching logic for the dashboard, dropping the number of database hits per page load from 150+ down to exactly 3.
Act V: A New Horizon
The transformation was night and day. API response times dropped to sub-200ms during peak load. Database CPU utilization plummeted from a precarious 95% to a stable 20%.
| Metric | Before Intervention | After Intervention |
|---|---|---|
| API Latency (P95) | 800ms+ | ~45ms |
| Database CPU Usage | 95% (Peaking) | 20% (Stable) |
| Dropped Checkouts | 12+ per day | 0 |
Most importantly, the platform stopped dropping checkout requests. The churn halted. With their infrastructure finally stable, the company was able to confidently onboard a massive enterprise client the very next month.
Key Technical Improvements
- Composite Indexing: Reduced full-table scans to near zero, significantly decreasing query time and CPU overhead.
- BullMQ Implementation: Offloaded heavy file processing and email dispatches to a Redis-backed queue, freeing up the main thread.
- ORM Optimization: Resolved critical N+1 query problems within the primary dashboard, reducing database hits per page load by 98%.
- Zero-Downtime Migration: Successfully applied these architectural shifts without halting production or the product roadmap.
The Takeaway
Most scaling problems don't require shiny new technologies or a massive microservices rewrite. They require boring, fundamental software engineering: better indexing, smarter queues, and eliminating synchronous blockers. Keep your stack boring, and your API fast.
Rohit Nishad
I design and build scalable backend systems, AI integrations, and cross-platform apps for startups. Focusing on performance, reliability, and clean architecture.