The problem
The platform's backend could only handle 6 batches at a time. Every additional batch had to wait in line, so throughput was capped by the architecture rather than by demand or by the hardware underneath it.
That ceiling showed up in a few ways:
- Work queued up. As volume grew, jobs waited longer before they could even start.
- Scaling meant more of the same. Adding capacity within the existing design gave diminishing returns, because the bottleneck was in how the system was structured.
- Growth was constrained. Taking on more workload meant first solving a capacity problem that would only get worse.
The goal was not to tune around the edges, but to change the architecture so that capacity could grow with the business.
What we built
The work was led by Sachin Singh, Fork Labs' founder, and focused on re-engineering the backend architecture rather than patching the existing one.
The approach followed three steps:
- Find the real constraint. We traced where batches were actually being held back, so the redesign targeted the parts of the system that limited throughput instead of the parts that were simply easy to change.
- Re-engineer the backend around throughput. We restructured the backend so that it could process many more batches at once, removing the design limits that had capped it at six.
- Measure before and after. Capacity and efficiency were compared on the old and new architecture, so the improvement was measured rather than assumed.
Because the changes were architectural, the gains came from how the system worked, not from throwing more infrastructure at the same design.
Results
| Metric | Before | After |
|---|---|---|
| Batch capacity | 6 | 55 |
| Efficiency | Baseline | +68% |
The re-engineered backend raised batch capacity from 6 to 55, and the redesign delivered a 68% efficiency gain compared with the previous architecture.
For the platform, that meant:
- Far more work in parallel, so volume growth no longer turned directly into longer queues
- Headroom to grow, with capacity coming from the architecture rather than from adding more of the same resources
- A cleaner foundation for the next round of scaling work
If your backend hits a ceiling every time volume grows, the fix is often structural. Re-engineering the bottleneck can unlock many times more capacity from the same system.