Geospatial Tracking Platform

Topology Notes

• ·The location ingestion write path has two parallel destinations: Redis GEOADD for the live position surface (synchronous, part of the API response path) and Kafka location_updates topic for downstream consumers (outbox-based, not in the API response path). The API acknowledges the location update after Redis write; Kafka publication is async via the outbox relay.
• ·Redis geospatial index is keyed by fleet_id (or region_id) with entity_id as the ZSET member. GEOSEARCH queries by (center_lat, center_lon, radius_meters) with BYRADIUS and WITHDIST return entity IDs within range in O(N+log M) where N is the result count and M is the total member count. For proximity-critical dispatch queries, this must complete in < 10ms, which requires that the active entity count per ZSET stays below ~500,000 for typical hardware.
• ·TimescaleDB stores the full location history as a hypertable partitioned by received_at (1-hour chunks) and optionally by entity_id hash bucket for high-cardinality fleets. Continuous aggregates compute 1-minute and 15-minute rollups for route analytics and SLA dashboards. Chunk-level compression is applied to chunks older than 7 days, reducing storage to approximately 10% of uncompressed volume.
• ·Kafka location_updates topic carries raw position events consumed by: the geofence evaluation service, the customer-facing ETA service, the analytics pipeline, and the historical storage consumer writing to TimescaleDB. Topic partitioning must use entity_id (or a uniformly distributed hash thereof) as the partition key to ensure all updates for the same entity are processed in order by each consumer.
• ·Geofence definitions are loaded into the evaluation service at startup and reloaded on a configuration change event published to a geofence_config Kafka topic. The evaluation service maintains an in-memory R-tree spatial index of active geofences. Reload must be atomic: the service must not partially apply a new geofence configuration.