From 100 to 1,000 assets
The scaling crisis that nearly broke the platform, and what we changed.
The first hundred assets were easy. Each one reported, each one had a dashboard, and the team knew every site by name. Then the fleet grew, and the assumptions that worked at a hundred stopped working.
What broke
- Polling. We asked each device for its state on a schedule. At a thousand devices, the schedule became the bottleneck.
- Queries. Dashboards that were fast on a small table became slow when the table grew.
- Alerts. Threshold rules fired in bursts, and the team learned to ignore them.
- Support. A single-digit number of sites can be supported by memory. A thousand cannot.
What we changed
We moved from polling to a stream where devices push state and the platform consumes it. We separated the hot path (current state and alerts) from the cold path (history and reports). We rewrote alerts around trends and rates rather than single readings.
Most importantly, we stopped treating every asset as a special case. A site, a pack and a vehicle became three records with a shared identity model, not three bespoke integrations.
The lesson
Scaling is rarely a matter of a bigger server. It is a matter of removing assumptions that only held at the old size. The hundred-asset system was not a smaller version of the thousand-asset system. It was a different system that happened to work.
Where we are now
The platform handles a fleet whose size we no longer track per screen. The on-call rotation still knows the sites that matter, but the software is what watches the rest.