In a ride-hailing dispatch flow, how should candidate drivers found by a geo index be ranked using a separate ETA service?

## Two stages: shortlist, then rank In a **ride-hailing dispatch flow**, finding the "best" driver is split into two stages with very different costs: 1. **Candidate generation** - the in-memory **geo index** returns drivers near the pickup point. This is fast because it compares coordinates only. 2. **Ranking** - a separate **ETA service** predicts how long each candidate needs to drive to the pickup. This is slower because it reasons about the road network and traffic. How the ETA service computes its answers (routing algorithms, traffic models) is out of scope here. What matters is how dispatch **uses it as a dependency**. ## Why straight-line distance is not enough **Straight-line distance** (the great-circle distance between two coordinates) ignores everything between them: - **Barriers** - a driver 400 m away across a river may need a 6 km detour to the nearest bridge, while a driver 1.5 km away on the same bank arrives sooner. - **Road direction** - on a divided highway or a one-way street, a driver who just passed the pickup must loop around. - **Heading** - a driver moving away from the pickup is effectively farther than the distance suggests. - **Traffic** - two equal distances can differ by many minutes at rush hour. Riders feel **pickup time**, not distance, so ranking should use ETA. ## Building the shortlist The geo index query should return a **bounded** set: - nearest **K** available drivers (K around 20-50 is a common illustrative range), or all drivers within a radius capped at K; - filtered by **status** (available, not already holding an offer) and by **product** (vehicle size, accessibility); - widened in steps if too few drivers are found, rather than starting with a huge radius. The bound matters for cost. Assuming 1,000 ride requests per second and K = 30, the ETA service must produce 30,000 ETAs per second. Doubling K doubles that load, usually for a small gain, because the best driver by road is almost always among the nearest few dozen by distance. That is a practical observation, not a guarantee: a large barrier can push the true best driver outside the shortlist. ## Calling the ETA service well | Concern | Technique | |---|---| | Many candidates per request | One **batched** call: many origins, one destination | | Slow responses | A **timeout** well inside the dispatch latency budget | | Outages | A **circuit breaker** that stops calling a failing service for a while | | Repeated similar queries | A short-lived **cache** keyed by coarse origin cell, destination cell and time bucket | | Degraded mode | **Fallback** estimate: distance x a road factor / typical speed | The fallback is what keeps dispatch alive. A rough estimate from distance is worse than a real ETA but far better than refusing to match anyone. The ranking should record which mode was used so quality dashboards can separate degraded matches. ## Putting it together ```pseudocode function rankCandidates(pickup, productType): candidates = geoIndex.nearestAvailable(pickup, productType, limit = 30) if candidates is empty: return widenSearchOrQueue(pickup) etas = etaService.batch(origins = positions(candidates), destination = pickup, timeout = 150 ms) if etas failed or timed out: etas = [distance(c, pickup) * roadFactor / typicalSpeed for c in candidates] markDegraded() return candidates sorted by etas ascending ``` The timeout and road factor are illustrative. The output is an ordered list; the dispatcher then offers the ride to the top candidate and handles concurrency separately. ## Beyond pure ETA Ranking is often a **score**, not ETA alone: - the driver's recent acceptance behaviour (an offer likely to be declined wastes seconds); - how long the driver has been idle, for fairness; - the drop-off area, when it matters for balancing supply. ETA usually stays the dominant term because it is what the rider experiences. Adding terms should be measured against pickup time and completion rate, not assumed to help. ## Common mistakes - Calling the ETA service once per candidate instead of in one batch, multiplying round trips. - Letting the ETA call have no timeout, so a slow dependency becomes a dispatch outage. - Ranking by distance permanently because ETA felt expensive, and then wondering why pickups near rivers and highways are slow. - Growing K to fix rare misses, which raises ETA load on every request.