Isolating admin batch load from the user-facing service
When the admin system ran a large batch, the user-facing service slowed down. The cause was not in the view layer but in shared server resources.
- Node.js
- AWS EC2
Specification
- Organisation
- Nudge Healthcare
- Period
- 2024
- Role
- Root-cause analysis, API separation
Context
The user-facing service and the admin system shared server resources. A large admin batch slowed user-facing responses as well.
The symptom looked like a frontend performance problem. Looking only at the view layer would never have reached the cause.
Approach
Lining up the slowdowns with batch execution times pointed at shared server resources rather than the view layer.
I separated the user-facing API surface from the admin one, so admin workload no longer propagates into the user-facing service.
System
Two workloads that contended for one pool of resources, separated.
Before, user traffic and admin batches contended for one API surface and one resource pool. After, each has its own.
Boundaries
- No shareable measurement exists for this change, so no figure is claimed.
- Infrastructure-level placement decisions were made together with the infrastructure owner.