Ride-hailing platforms handle high-rate GPS updates from millions of drivers while keeping latency low for matching. One described approach estimates the required throughput by assuming frequent location reports (for example, 5 million drivers reporting every 4 seconds, yielding about 1.25 million location packets per second). At this scale, traditional REST calls are presented as inefficient due to per-request TCP and TLS handshakes and sizable HTTP headers relative to small GPS payloads. Instead, the system uses persistent connections and compact serialization, such as MQTT with lightweight headers and QoS options, or gRPC bidirectional streaming with Protobuf and flow control. On the mobile side, additional reductions come from batching multiple GPS samples into fewer uploads, adaptive reporting frequency based on driver state (idle, moving, on-trip, stationary), and techniques like dead reckoning and Kalman filtering to smooth noisy GPS measurements.

For rider-to-driver matching, the second source describes spatial indexing. It argues that brute-force distance comparisons across millions of drivers are too slow and instead uses hexagonal spatial indexing via Uber’s H3. A rider’s coordinates map to an H3 cell (e.g., resolution 8), then the system searches a small neighborhood (a K-ring) of nearby cells, typically starting with 7 cells and expanding if needed. Driver locations are stored in Redis (in-memory) using Redis GEO or Redis SETs keyed by H3 cell, enabling fast radius or cell-based lookups.