Skip to content
ApexSutra

Reference build 03 · Logistics

Fleet Telemetry

High-volume position ingest with an offline-first driver app and out-of-order event handling.

Reference architecture · illustrative
The problem

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.

React NativeNode.jsTimescaleDBRedisKubernetesGrafana

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.

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.

  • 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.

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