Mobility systems built for unreliable networks
Dispatch, live tracking, driver apps and the routing behind them — designed around the fact that vehicles go through tunnels, phones lose signal, and events arrive minutes late and in the wrong order.
Where these systems usually break
Offline is the normal case
Devices must queue, retry and reconcile. We make event ordering and idempotency explicit instead of hoping the network cooperates.
Real-time load at scale
Thousands of position updates per second, and a dispatcher screen that has to stay smooth. Elixir earns its place here.
Routing meets real constraints
Shift lengths, vehicle types, time windows, depots. Optimisation is only useful once the constraints are modelled honestly.
Everything in mobility is eventually consistent. The design question is what the dispatcher and the customer are told while the truth catches up.
Events, not state updates
We record what a device reported and when it was received as separate facts, which makes late and duplicate messages a normal case rather than a bug. Current state is derived, so it can always be rebuilt.
That model also makes disputes answerable: it is possible to show exactly what was known at 14:32 and why the system acted as it did.
Latency budgets on screen
A dispatcher tolerates a five-second-old position if the interface is honest about it. We show data freshness rather than pretending to a precision the network cannot deliver.
The same discipline applies to customer-facing ETAs, where an unreliable promise costs more than a wider window.
Show the dispatcher how stale the data is, and they will trust the system twice as far.
Work like this usually touches
Running fleets, drivers or deliveries on software that strains?
Send the context you have — a repo, a diagram, or three paragraphs of frustration. We reply within one business day.