Reference build 03 · Logistics
Fleet Telemetry
High-volume position ingest with an offline-first driver app and out-of-order event handling.
What we'd be solving.
A fleet operator needs live vehicle visibility and reliable proof of delivery. Drivers work through areas with no coverage, position pings arrive at a rate a relational database cannot absorb, and events frequently arrive out of sequence.
The approach
Four decisions that shape everything else.
- 01
Split the ingest and query paths
Raw pings land in a time-series store sized for write throughput. Operational queries read from a narrow projection holding last-known state, so dashboards never contend with ingest.
- 02
The driver app owns a local write log
Actions are recorded locally first and synced opportunistically. Conflict policy is decided per action type up front — last-write-wins is wrong for proof of delivery.
- 03
Event time, not arrival time
State transitions are ordered by device-reported timestamps with a bounded lateness window, so a delayed dispatch event cannot overwrite a delivery that already happened.
- 04
Routing as a constraint problem
Capacity, driver hours and delivery windows are expressed as constraints for a solver, rather than approximated with shortest-path heuristics that fail in practice.
Fleet Telemetry, in one picture.
- 01Driver appWrites to a local log first; connectivity is not a precondition
- 02Ingest pathOrdered by event time, not server arrival time
- 03TimescaleDBTime-series storage sized for high-volume position writes
Deliberately off the main path
- Query pathSplit from ingest so a heavy read cannot slow the write path that vehicles depend on.branches from 02 Ingest path
- RoutingTreated as a constraint problem rather than a shortest-path lookup.branches from 03 TimescaleDB
What we rejected
The alternatives, and why they lost.
Anyone can list the technology they chose. What tells you whether a team can be trusted with your system is whether they can explain what they didn't choose.
| Option rejected | Why it lost |
|---|---|
| Writing every ping to PostgreSQL | Works in a pilot, collapses at fleet scale. The write volume and retention profile are what time-series engines exist for. |
| Requiring connectivity in the driver app | Guarantees the app is unusable in exactly the conditions it is needed. Offline capability is not an enhancement here. |
| Ordering events by server arrival time | Produces state that contradicts physical reality whenever the network delays a message. |
Other reference builds
Keep reading.
Start here
Tell us the problem.
We'll be honest about the fit.
A first conversation costs nothing and is useful even if you go elsewhere — you'll leave with an architecture opinion and a realistic sense of scope.
- Reply within 24 hours
- No sales sequence