Skip to main content
INS // Insights

Real-Time Fleet Tracking Software — Architecture We Use

Updated July 2026 · 4 min read

A logistics operator running dozens of delivery vehicles came to us running fleet visibility off a spreadsheet updated by drivers texting their location — a process that broke down the moment volume grew past a handful of trucks. Here's the real-time tracking system we built to replace it.

The Core Requirements

Fleet tracking sounds simple — put a dot on a map — until you account for the real constraints: vehicles losing signal in coverage gaps, dozens of vehicles updating position every few seconds, dispatchers needing instant geofence alerts, and a UI that has to stay responsive with a live map rendering continuous position updates.

Data Ingestion: GPS to Event Stream

Each vehicle's GPS unit reports position, speed, and heading over cellular at a configurable interval (typically 10-30 seconds). We ingest this through an MQTT broker (AWS IoT Core) rather than a direct HTTP API, since MQTT handles intermittent connectivity and reconnection far better for mobile, coverage-gap-prone devices.

def on_position_update(topic, payload):
    vehicle_id = topic.split("/")[2]
    position = json.loads(payload)

    # Write to time-series store for history/replay
    timestream_client.write_records(
        DatabaseName="fleet_tracking",
        TableName="vehicle_positions",
        Records=[build_timestream_record(vehicle_id, position)]
    )

    # Publish to WebSocket connections for live dashboard
    websocket_manager.broadcast(f"fleet/{vehicle_id}", position)

    # Check geofence rules
    check_geofence_triggers(vehicle_id, position)

Live Map Rendering Without Overwhelming the Browser

Pushing every raw GPS update straight to the browser at scale causes map rendering to choke, especially on mobile dispatcher devices. We throttle outbound updates per vehicle (position updates are batched and smoothed client-side using interpolation between received points) so the map shows fluid vehicle movement without requiring a new render on every single GPS ping.

Geofencing and Alerts

Dispatchers define geofence zones (delivery zones, restricted areas, depot boundaries) as GeoJSON polygons. Each incoming position update is checked against active geofences using a point-in-polygon algorithm, and entry/exit events trigger configurable alerts — SMS to a dispatcher, a webhook to the client's existing operations system, or an in-app notification.

def check_geofence_triggers(vehicle_id: str, position: dict):
    point = Point(position["lng"], position["lat"])
    for geofence in active_geofences_for_vehicle(vehicle_id):
        is_inside = geofence.polygon.contains(point)
        was_inside = get_last_geofence_state(vehicle_id, geofence.id)
        if is_inside and not was_inside:
            trigger_alert(vehicle_id, geofence.id, event="entry")
        elif not is_inside and was_inside:
            trigger_alert(vehicle_id, geofence.id, event="exit")
        set_geofence_state(vehicle_id, geofence.id, is_inside)

Handling Coverage Gaps and Data Backfill

Vehicles moving through areas with poor cellular coverage buffer position data locally on the GPS unit and transmit the backlog once connectivity resumes. The ingestion pipeline handles out-of-order and delayed messages by timestamp rather than arrival order, ensuring the historical replay and reporting views remain accurate even after a gap.

Historical Replay and Reporting

Beyond live tracking, the client needed route history for delivery confirmation disputes and driver performance review. Storing position data in Amazon Timestream (a time-series database purpose-built for this access pattern) lets the system efficiently query "where was vehicle 42 between 2pm and 3pm last Tuesday" without scanning the entire dataset.

Results

The client moved from manual driver check-ins to live visibility across their entire fleet, cut delivery dispute resolution time significantly since GPS history now settles "was the driver actually there" questions definitively, and gained automated geofence alerting that catches route deviations dispatchers previously only discovered from customer complaints.

Need custom software for field operations or logistics? Discuss your project — 907-841-8407 or contact@rutagon.com.

Frequently Asked Questions

What technology is used for real-time vehicle position updates?

We typically use MQTT (via AWS IoT Core) for device-to-cloud ingestion, since it handles intermittent mobile connectivity better than direct HTTP polling, and WebSockets to push live updates to dispatcher dashboards without requiring the browser to poll repeatedly.

How does the system handle vehicles losing GPS signal or cellular coverage?

GPS units buffer position data locally during coverage gaps and transmit the backlog once connectivity resumes. The ingestion pipeline processes these by timestamp rather than arrival order, so historical data remains accurate even with delayed transmission.

Can geofencing trigger custom alerts to our existing dispatch software?

Yes. Geofence entry and exit events can trigger SMS, in-app notifications, or webhooks to integrate with existing dispatch, ERP, or customer notification systems.

How many vehicles can this architecture support?

The event-driven, queue-based design scales horizontally — the ingestion pipeline and WebSocket broadcast layer can handle fleets from a handful of vehicles up to several thousand without architectural changes, though database and dashboard tuning may be needed at very large scale.

Do drivers need special hardware, or can this use existing GPS devices?

The architecture is hardware-agnostic as long as the device can report position data via a standard protocol. Many clients use existing commercial GPS trackers or mobile apps rather than requiring custom hardware.