Adding "live asset tracking" to an internal tool is one of those seemingly simple requests that never is. The challenge isn’t slapping a GPS chip or an RFID reader on an asset, but rather architecting a data system that can ingest, identify and sensor events via a multitude of different protocols, normalize everything, and still return the result in under a second when a stakeholder asks, “Where is asset #4471 right now?” This post shares architectural patterns that usually hold up in production, covering how identity, location, and sensor-based tracking systems are usually designed.
3 Data Types, 3 Different Update Rates
The first design anti-pattern is treating all asset data the same way.
Generally, you have three separate streams: Identity events, i.e. RFID or barcode/QR scans. These events occur rarely but are typically highly reliable (i.e., either scanned or not scanned).
Location events, i.e.
GPS or Wi-Fi triangulation. Events are usually continuous or interval-based and vary widely in terms of signal environment (indoor GPS can degrade, and Wi-Fi trilateration can have inaccuracies). Sensor events, i.e.
Temperature, vibration or shock sensor data. Sensor data is often high-frequency but only of interest when thresholds are triggered. Forcing these three data types into a single schema or ingest stream usually results in downstream pain.
An easier design isolates the streams by type and treats them individually, only joining on asset ID at read time.
*Protocol Reality *
Expect Multiple Transport Protocols Unless you built the hardware from scratch, you'll be managing several different protocols: MQTT over Cellular (used by GPS tracking devices) LoRaWAN (popular for long-range, low-power IoT devices where battery life is more critical than frequent updates) BLE advertisements (used by indoor RTLS solutions) RFID reader logs (often reported via a local edge device) An MQTT broker (or similar message queueing solution like RabbitMQ or Kafka, although MQTT is standard for this use case) will simplify your life greatly by de-coupling the ingestion layer from the devices, avoiding a proliferation of custom device-parsing logic across your codebase. The message queue’s job is then to provide these disparate data types to a normalization layer, which will translate them all into a common event format, before ingesting them into your databases. The Importance of Edge Filtering Sensor data from devices can get very noisy if the data rate is too high. A motion sensor, for instance, might send dozens or hundreds of readings a second while the asset is stationary, generating immense volumes of mostly irrelevant data.
Filtering and processing this at the edge (the asset itself or a local gateway device) – transmitting data only when events cross certain thresholds or when there’s a significant change – can drastically reduce costs associated with network bandwidth, data transmission, and cloud storage.
It can also mean less work downstream as your data pipeline is dealing with meaningful signals rather than a constant stream of sensor noise. This concept aligns closely with predictive maintenance; value lies in recognizing patterns before they cause failure rather than storing every piece of vibration data. Geofencing as a Query, Not Just a Feature Geofencing is frequently treated as a feature (“alert me if the asset moves outside this zone”) instead of as a specific type of query.
When framed as “is point P at time T within polygon/radius Z?”, it opens up re-usability of the same core spatial querying logic for various purposes, such as analyzing time spent within zones, identifying route deviations, or detecting anomalies in travel patterns. Spatial database extensions like PostGIS (or specialized cloud solutions like Amazon Aurora geospatial functions) are built for handling this scale efficiently. Implementing custom point-in-polygon checks in your application code often doesn’t scale to thousands of assets.
A Baseline Architecture A basic, but functional architecture for a real-time asset tracking system:
Message Broker: MQTT broker that handles ingestion from devices and different protocols.
Normalization Service: A small service to map diverse device events into a standard event format. Data Storage: Time-series database for sensor data. Relational/Document database for identity and latest location. Geospatial index for efficient geofence querying.
API Service: A querying layer that can retrieve the latest asset state, history, and handle geofence checks across all three data types.
The key is understanding that identity, location, and sensor data are distinct data types that share a common key – the asset ID. If you need help understanding protocol options for various types of trackers before designing your architecture, check out AssetTrackPro
I’d be curious to hear how others on the team have handled ingestion of diverse protocols and combined noisy sensor data like GPS and BLE into a singular “current location.”
Top comments (0)