System Architecture: Core Components of Location Tracking

Ingestion Layer
Devices send location updates to ingestion servers. Use WebSocket or long-polling for persistent connections. UDP reduces overhead for high-frequency updates but loses delivery guarantee. HTTPS works but connection overhead is high for frequent small payloads.
Load balance by entity ID, not randomly. All updates from one driver go to one server. This enables local caching and deduplication. The server can skip writes if position has not changed significantly.
Hot Storage
Store current position in fast key-value store like Redis. Key is entity ID, value is lat/lon plus timestamp. Writes are simple key updates, O(1). Reads are key lookups, O(1). No spatial indexing at this layer.
This layer optimizes for write throughput. It answers "where is driver X right now" instantly. It does not answer "which drivers are near location Y" because there is no spatial index. Different layer handles spatial queries.
Spatial Index Layer
Separate system maintains spatial index of current positions. Receives position updates from hot storage via streaming or polling. Updates spatial index asynchronously. May be 1-5 seconds behind hot storage.
Spatial index answers "which drivers are near location Y." Use geohash, quadtree, or in-memory grid. Optimize for read performance since spatial queries are less frequent than position updates. Rebuild periodically from hot storage to handle drift.
History Storage
Archive positions for analytics, billing, disputes. Write to time-series database or append-only log. Query patterns differ: "show trip route" not "find nearby drivers." Optimize for sequential reads of one entity time range.
🎯 When To Use: This three-layer architecture separates concerns: hot storage for current state, spatial index for proximity queries, history for analytics. Each layer optimizes for its specific access pattern.

💡 Key Takeaways

✓Ingestion: WebSocket or UDP for high-frequency updates; load balance by entity ID

✓Hot storage: Redis for current position; O(1) write and read; no spatial index

✓Spatial index: separate layer, async updates, optimized for proximity queries

✓History storage: time-series for analytics; different query patterns

✓Three layers separate write-heavy current state from read-heavy spatial queries

📌 Interview Tips

1Explain layer separation: Redis answers where is X, spatial index answers what is near Y, time-series answers where was X

2Load balance by entity ID: all updates from driver 123 go to same server for local deduplication

3Spatial index can lag 1-5 seconds; acceptable for find-nearby queries

← Back to Real-time Location Tracking Overview