Skip to content

Lifetime of a Tracker Device

Pre-Manufacturing Phase

  • Glimpse generate public/private key pairs
  • The public keys are sent to the manufacturer
  • The devices are manufactured with a custom firmware, each with a public key
  • The tracker devices are sent to Glimpse

Order Processing Phase

  • When a customer places an order Glimpse allocate devices, by MAC address to a customer

System Setup Phase

  • The client is created on the system
  • The brand is created and added to the client
  • The production run for the clients brand is created
    • Delivery locations are configured for the production run with geofence sizes
    • Storage locations are configured for the production run with geofence sizes
  • The trackers are imported into the system to the production run

Data Collection Phase

  • The system fetcher service requests location reports from apple, for the trackers by hashed public key, where the trackers are between the production run start and end date.
  • If a tracker doesn't show up on a response from apple it remains in a queue
    • Queued trackers will continue to be queried for the life of the production run, and will be queried to fetch a maximum of 7 days history
    • Failed trackers use exponential backoff (2x, 4x, 8x, up to 16x) with maximum cap to prevent indefinite delays
    • Successful fetches reset backoff factor to 1, ensuring recovered trackers get normal priority
  • Queuing is done in such a way to ensure every tracker gets a fair turn and rotates through the queue
    • Uses Redis sorted set (ZSET) with timestamps as scores for fair scheduling
    • Failed trackers don't monopolize queue - they're scheduled further in future based on backoff
    • Only trackers due for processing (based on timestamp scores) are claimed by workers
  • The location reports are aggregated into hourly and daily reports
  • The geolocation service carries out a lookup of the nearest city to update the location history

Status Processing Phase

  • The status service uses the aggregated data to find if the trackers location has entered a delivery or storage location, and updates a status history record
  • Status determination follows priority: DELIVERED (in delivery geofence) > IN_STORAGE (in storage geofence) > IN_TRANSIT (outside all geofences)
  • Geofence detection uses PostGIS ST_DWithin function for accurate distance calculations
  • Only delivery/storage locations associated with the tracker's production run are considered
  • Status changes are recorded with timestamps and location references for audit trail
  • Batch processing is used for efficient status updates across multiple trackers

User Access Phase

  • A user is able to view the location of the devices related to the clients they are related to
  • Users can view current status (DELIVERED/IN_STORAGE/IN_TRANSIT) and status history
  • Location data is filtered based on user's client permissions

Lifecycle End Phase

  • Once the end date of the production run is reached the system no longer queries apple for the location of the related trackers.
  • Historical data remains accessible for reporting and analysis