A micromobility operator manages tens of thousands of vehicles in cities. What does the fleet management architecture need beyond tracking?

Beyond location

Location alone answers almost none of the operational questions. The system needs state — available, in use, low battery, unreachable, damaged, in maintenance, out of service area — and it needs the state to be correct even when the vehicle has not reported recently.

What the architecture requires

• A state machine per vehicle with defined transitions and defined behaviour on missing telemetry. A vehicle that has not reported for six hours is in a distinct state, not simply showing its last known one — presenting stale data as current is how operations teams are sent to places where nothing is.
• Last-reported timestamps surfaced everywhere, so every consumer can judge staleness.
• Command delivery with acknowledgement and expiry. A lock command sent to an offline vehicle must not be delivered three hours later when the situation has changed — commands need a validity window.
• Battery and health prediction, so intervention is scheduled before a vehicle strands rather than after.
• Geofencing evaluated on-device as well as server-side, since the device must enforce a boundary while offline.
• Operational routing, since the actual product for the operations team is an ordered list of what to do next, not a map.

The physical-world realities

Vehicles are moved, stolen, vandalised and submerged. The system must handle a vehicle that stops reporting permanently, one that reports from an impossible location, and one that reports implausible sensor values. Sensor data is untrusted input and needs validation exactly like user input.

The measure that matters

Not fleet size but available vehicle-hours in the right places. That reframes the system's purpose from tracking to availability, which changes what gets built: prediction and dispatch rather than dashboards.