What is Real-time Location Tracking?

Definition
Real-time location tracking continuously updates the positions of moving entities (drivers, packages, devices) and makes that data available for queries within seconds. The challenge is handling high update rates while maintaining query performance.
Why Real-time is Hard
Static location data (restaurants, stores) changes rarely. Index once, query forever. Moving entities change constantly. 1 million drivers updating every 5 seconds is 200,000 writes per second. Each write potentially changes which spatial cell contains the entity.
The write rate overwhelms traditional spatial indexes. B-trees handle reads well but writes cause rebalancing. Spatial indexes optimized for read-heavy workloads struggle with write-heavy tracking. Different architecture needed.
Freshness vs Consistency Trade-off
Perfect consistency means every query sees the latest position. This requires synchronous index updates on every write. Latency spikes when index updates are slow. Throughput drops when writes must wait.
Eventual consistency accepts slight staleness. Write position to fast in-memory store. Asynchronously update spatial index. Queries may see positions 1-5 seconds old. For most use cases, a driver position from 3 seconds ago is good enough. The ETA calculation is approximate anyway.
Scale Considerations
Updates are write-heavy and globally distributed. A driver in Tokyo updates independently of a driver in London. Partition by region to isolate writes. Queries are typically local: find drivers near me. Local queries hit local partition.
💡 Key Insight: Real-time tracking inverts the typical database workload. Instead of read-heavy with occasional writes, it is write-heavy with occasional reads. Design for write throughput first, then optimize read paths.

💡 Key Takeaways

✓Moving entities generate continuous writes; 1M drivers at 5s intervals is 200K writes per second

✓Traditional spatial indexes struggle with write-heavy workloads

✓Eventual consistency accepts slight staleness for better throughput

✓1-5 second staleness is acceptable for most location queries

✓Partition by region: writes are distributed, queries are local

📌 Interview Tips

1Calculate write rate: 1 million entities updating every 5 seconds means 200,000 writes per second

2Explain consistency trade-off: synchronous index update ensures freshness but limits throughput

3For ride-sharing, accept that driver position may be 3 seconds old; ETA calculation handles the approximation

← Back to Real-time Location Tracking Overview