Ride-hailing driver matching

Keep live positions in memory, indexed by geo cell (H3 or geohash), updated every few seconds. For a request, read the rider's cell and its neighbouring rings until you have enough candidates, filter by availability and vehicle type, then rank by road ETA from a routing engine.

Drivers send location updates every few seconds to a location service that keeps the latest position in an in-memory geospatial index partitioned by city or cell. A rider request goes to a matching service that queries nearby available drivers, scores them by ETA and other factors, offers the ride to the best driver with a timeout, and on acceptance atomically marks the driver busy and creates the trip.

Straight-line distance is a first filter; real ETAs come from a routing engine over the road graph with live traffic (precomputed contraction hierarchies for speed). Compute ETAs only for a shortlist of nearby candidates to save cost.

Each offer has a short timeout (around 10–15 seconds); on timeout or rejection, the matcher offers to the next best driver. Track acceptance rates, and avoid offering the same rider to many drivers at once unless using a broadcast model.

Every hexagon's neighbours are the same distance from its centre, so a ring of cells approximates a circle well. Square cells have corner neighbours that are further away and edges that distort with latitude. Both work; H3 makes radius searches and surge-pricing areas more uniform.

Reserve the driver atomically before sending an offer: a compare-and-set on the driver's state (available → offered) in Redis or the database. If it fails, move to the next candidate. The reservation expires if the driver does not answer.

Keep only the latest location per driver in memory (Redis GEO, H3-indexed maps or a custom service), partitioned by region, with updates written to a stream for analytics. Do not write every ping to a relational database.

Compare demand (requests) with supply (available drivers) per area and time window, compute a multiplier with smoothing and caps, show it to riders before booking, and use it to attract drivers to busy areas.

Collect requests and available drivers over a short window (a few seconds) and solve an assignment problem that minimises total pickup time across all pairs, which beats nearest-driver greedy matching in dense areas.

Model the trip as a state machine (requested, driver assigned, arriving, in progress, completed, cancelled), persist each transition in a strongly consistent store, and use conditional updates so concurrent events cannot apply invalid transitions.

Partition by city or region: each region has its own location index, matching workers and possibly database shards, since riders and drivers rarely interact across cities. A global layer handles accounts and payments.

Push driver location updates to the rider app over WebSockets or a streaming connection at a few-second interval, smoothing movement on the client between updates.

Requests are persisted with state, so another instance can resume them; driver locks have TTLs so drivers are not stuck as busy, and riders see a retry state rather than silent failure.

Store the reservation with pickup time and location, start matching a configured window before pickup with wider search radius and incentives, notify the rider when a driver is assigned, and have a fallback that escalates priority or offers compensation if no driver accepts in time.

Shed non-critical work such as ETA refinements for distant drivers, widen batching intervals, cap requests per area with clear 'high demand' messaging, scale the city's matcher shard, and protect the trip state store with backpressure.

Cells turn 2D proximity into key lookups: query the rider's cell and its neighbours to get candidates quickly, then refine by exact distance and ETA. H3's hexagons have uniform neighbour distances, making rings more accurate.

Check location plausibility (speed between pings, jumps), compare with network and sensor data, detect emulators, and flag suspicious trips for review.

Match riders whose routes overlap, insert pickups and drop-offs into an existing route if the detour stays under limits, and recompute ETAs for everyone in the vehicle.

Use historical trips, time of day, events, weather and holidays in forecasting models per area, and use predictions to reposition drivers and set surge in advance.

With 5 million active drivers sending a ping every 4 seconds, that is about 1.25 million updates per second globally, which is why updates go to in-memory, region-partitioned indexes.

Use live traffic data, historical speeds by time of day, map-matching of GPS traces to roads, and correct with machine learning trained on actual trip times.

Allow cancellation within rules, free the driver immediately, apply fees after a grace period, and feed cancellation patterns into matching (drivers or riders who cancel often).

Driver assignment and payments need strong consistency to avoid double booking or charges; driver locations and ETAs can be eventually consistent and slightly stale.

Target incentives at areas and times where supply forecasts fall short, cap budgets per region, measure incremental supply with experiments rather than raw participation, and avoid incentives that pull drivers away from other busy areas.

Snap requested points to valid pickup spots on the road graph using map data and past successful pickups, suggest nearby better spots, allow chat or call between rider and driver through masked numbers, and update the pickup pin live.

Estimate route distance and time from the routing engine, apply the city's base, per-km and per-minute rates plus current surge and fees, lock the quote for a short time, and store it with the trip so the charged fare matches unless the route changes materially.

Detect anomalies like long unexpected stops or route deviations from the location stream, prompt both parties, offer one-tap emergency help, and let riders share a live trip link that shows the car and route to trusted contacts until the trip ends.

Simulate historical demand and supply with replay simulators, compare metrics like pickup time and match rate, then run regional A/B tests or switchback experiments.

Alternating between treatment and control over time windows within a city, because riders and drivers interact and per-user A/B tests would interfere with each other.

Time to match, pickup ETA, request-to-acceptance rate, cancellation rate, driver utilisation and earnings, and completion rate.

Mask phone numbers with proxy calling, share precise locations only during active trips, limit data retention and restrict internal access to trip histories.

Stream trip events through change data capture into a data lake or warehouse, keep only active trip state in the operational store, and build analytics, pricing models and dashboards from the warehouse copy.

1. AAlphabetical order
2. BStraight-line distance
3. CEstimated road travel time (ETA)Correct answer
4. DDriver's rating only

Why: Road networks, one-way streets and traffic make ETA the real measure of how soon a car arrives.

1. AAn in-memory geospatial indexCorrect answer
2. BA relational row per ping
3. CThe CDN
4. DRider phones

Why: Updates arrive every few seconds.

1. AOffering to all drivers
2. BAtomic conditional update or lock on assignmentCorrect answer
3. CHoping it is rare
4. DAsking riders to wait

Why: Only one trip can claim the driver.

1. AOffer to the next best driver after a timeoutCorrect answer
2. BWait forever
3. CCancel the ride
4. DCharge the rider

Why: Short offers keep riders from waiting.

1. AEmail logs
2. BA relational table with an index per ping
3. CAn in-memory geo indexCorrect answer
4. DObject storage

Why: Very frequent, short-lived updates fit an in-memory index; history can be streamed elsewhere.

1. AETAs are always equal
2. BIt is required by maps
3. CShortlists are random
4. DRouting calls are expensiveCorrect answer

Why: Filter by distance first.

1. AMatching faster always
2. BIgnoring distance
3. CUsing fewer drivers
4. DMinimising total pickup time across pairsCorrect answer

Why: An assignment problem.

1. AOne server per rider
2. BA single database row
3. CPartition by regionCorrect answer
4. DOne global queue

Why: Riders and drivers are local.

1. ARider ratings
2. BCar colours
3. CApp versions
4. DDemand with supply in an areaCorrect answer

Why: Then smooths and caps a multiplier.

1. AHeat maps
2. BDriver assignment and paymentsCorrect answer
3. CDriver map icons
4. DETA estimates

Why: Avoid double booking and charges.

1. AStreamed location updates smoothed on the clientCorrect answer
2. BRefreshing the page
3. CEmail updates
4. DSMS every second

Why: Updates stream over WebSockets.

1. AA window before the pickup timeCorrect answer
2. BAt booking time only
3. CAt the exact pickup second
4. DAfter the rider arrives

Why: Drivers near the time and place are the useful candidates.

1. APayments
2. BDriver locations
3. CNon-critical refinements like distant ETAsCorrect answer
4. DTrip state writes

Why: Core matching and trip consistency must keep working.

1. AA payment token
2. BA road segment's speed
3. CA user account
4. DA small geographic areaCorrect answer

Why: Both encode an area on the map, so nearby points share a cell or a prefix.

1. AThey encrypt locations
2. BUniform neighbour distancesCorrect answer
3. CThey are smaller files
4. DThey avoid GPS

Why: Rings of neighbours are accurate.

1. ACar colour
2. BApp theme
3. CBattery level only
4. DImplausible speeds and jumpsCorrect answer

Why: Check location plausibility.

1. AAbout 12,500
2. BAbout 125
3. CAbout 125 million
4. DAbout 1.25 millionCorrect answer

Why: 5 million divided by 4.

1. AAlways
2. BNever
3. CThe car is empty
4. DThe detour stays under limitsCorrect answer

Why: Recompute ETAs for all.

1. ANo testing
2. BSurvey only
3. CSwitchback experimentsCorrect answer
4. DPer-user A/B only

Why: Riders and drivers interfere.

1. AThe trip is charged
2. BIt expires via a TTLCorrect answer
3. CIt stays forever
4. DThe driver is banned

Why: Drivers must not stay stuck.

1. AIn the CDN
2. BAs a state machine with conditional updatesCorrect answer
3. COnly in the app
4. DIn logs

Why: Invalid transitions are rejected.

1. AFixed speeds
2. BRandom noise
3. CLive traffic plus models trained on real tripsCorrect answer
4. DStraight-line distance only

Why: Map-matching helps too.

1. ANumber of drivers who opt in
2. BTotal budget spent
3. CSocial media mentions
4. DIncremental supply measured in experimentsCorrect answer

Why: Paying drivers who would have driven anyway adds nothing.

1. AThe rider's home address
2. BThe nearest airport
3. CRandom nearby points
4. DValid road positions and past good pickupsCorrect answer

Why: Drivers need a reachable spot on the road.

1. ALocked briefly and stored with the tripCorrect answer
2. BRecomputed silently at the end
3. CHidden until arrival
4. DBased on the driver's choice

Why: The charge should match what the rider accepted.

1. AApp store reviews
2. BWeekly reports
3. CThe live location stream compared to the planned routeCorrect answer
4. DPayment logs

Why: Real-time location reveals unexpected stops or detours.

1. AProxy calling that masks numbersCorrect answer
2. BSharing them publicly
3. CEmailing them
4. DPrinting on receipts

Why: Privacy for both sides.

1. ADesign logos
2. BEncrypt data
3. CStore images
4. DReposition drivers before peaksCorrect answer

Why: Supply meets predicted demand.

1. AMap style
2. BPickup ETA and time to matchCorrect answer
3. CApp size
4. DServer count

Why: Riders feel these directly.

1. AThe CDN
2. BA stream for analyticsCorrect answer
3. CThe relational trips table per ping
4. DEmail

Why: Keep the hot path in memory.

1. AFree a ride
2. BBan the driver
3. CRestart the app
4. DIncur a feeCorrect answer

Why: Discourages late cancellations.

1. AThe matching cache
2. BA warehouse fed by change data captureCorrect answer
3. CThe live trip state store
4. DThe driver app

Why: Analytics should not load operational systems.