Subsystem 01
GPS telemetry ingestion
Terminates cellular connections and decodes GPS packets
Typical stack
Go gateway + MQTT
Reference architecture
Real-time geospatial fleet tracking and geofencing engine
Track fleets of 100,000+ delivery vehicles in real time, with sub-second GPS ingestion, geofence alerts and spatial queries that stay fast.
Design constraints
What the design has to hold to
Targets for the scenario this reference is sized for. A real engagement starts by replacing them with your own numbers.
- 0150,000 GPS coordinates per second, with geofence breaches detected in under 200 ms
- 02Spatial indexes that answer polygon and radius queries in under 10 ms
- 03Low-bandwidth vehicle telemetry in compact binary formats
- 04Route playback across months of journey history
Component topology
System components and technologies
Subsystems with separate responsibilities, clear contracts between them and storage that scales on its own. The stack named for each is typical, not mandatory.
Stack topology
Real-time geospatial fleet tracking and geofencing engine
Illustrative reference architecture
- 01
GPS telemetry ingestion
Terminates cellular connections and decodes GPS packets
Go gateway + MQTT
- 02
In-memory geofence engine
Real-time geofence evaluation and proximity tracking
Tile38 in-memory spatial database
- 03
Persistent geospatial store
Route history and complex GIS queries
PostgreSQL + PostGIS
- 04
Live map dispatcher
Streams moving vehicle markers to dispatcher dashboards
Next.js + Mapbox GL + WebSockets
Subsystem 02
In-memory geofence engine
Real-time geofence evaluation and proximity tracking
Typical stack
Tile38 in-memory spatial database
Subsystem 03
Persistent geospatial store
Route history and complex GIS queries
Typical stack
PostgreSQL + PostGIS
Subsystem 04
Live map dispatcher
Streams moving vehicle markers to dispatcher dashboards
Typical stack
Next.js + Mapbox GL + WebSockets
Data lifecycle
End-to-end data flow
Each vehicle tracker publishes its position (lat, lng, speed, heading) over MQTT.
The Go gateway decodes the binary packet and publishes the update to Tile38.
Tile38 checks the position against active geofence polygons (warehouses, customer drop-offs).
Entering or leaving a geofence fires a webhook that sends the customer an SMS.
A batch writer stores trajectories in PostGIS tables for long-term route analysis.
Reliability and resilience
Failure modes and how each is contained
Failure mode 01
GPS drift and multipath interference
Mitigation
Kalman filtering smooths noisy coordinates, and map matching snaps them to the road network.
Failure mode 02
PostGIS spatial index bottlenecks
Mitigation
Partition tracking tables by date and vehicle_id, with GiST indexes on each partition.
Failure mode 03
Cellular dead zones in transit
Mitigation
Trackers buffer coordinates locally and send the backlog when 4G or 5G returns.
Questions
What teams ask about this design
Tile38 runs entirely in memory and is built for real-time geofence checks, while PostGIS handles complex queries over persistent history.
With Mapbox GL or deck.gl, using WebGL instanced rendering that updates coordinate buffers instead of recreating DOM elements.
Planning a system like this?
Send us your requirements, expected load and budget. We'll reply within one business day with an honest read on the design, and on whether we're the right team to build it.