Skip to main content
Xsphere
  • Home
  • Our Work
  • Our history
  • Blog
  • with us
  • Contact
Xsphere
  • Home
  • Our Work
  • Our history
  • Blog
  • with us
  • Contact

October 16, 2026 · 2 min read

Finding the Nearest Driver Without Scanning Every Driver

Engineering
Finding the Nearest Driver Without Scanning Every Driver

The first version of nearest-driver search is always the same: take every available driver, compute the distance to the rider, sort, take the closest few. It is correct, it is five lines, and it works perfectly during testing.

It stops working because its cost grows with the number of drivers, and it runs on every single ride request. The two curves multiply.

Make the search area small first

The insight that fixes it is that you should never consider a driver who is obviously too far away. Rather than measuring everyone, divide the map into cells, find which cell the rider is in, and only examine drivers in that cell and its neighbours.

You are turning a problem that scales with total drivers into one that scales with local density. That is the whole game.

Straight-line distance is not travel time

A driver three hundred metres away across a river is further, in every sense the rider cares about, than one eight hundred metres away on the same road. Proximity gets you a shortlist of candidates. Ranking that shortlist properly needs routing.

The split is deliberate: cheap filtering to get from thousands to a handful, expensive accurate evaluation on the handful.

The data moves constantly

The complication specific to this problem is that every driver's position changes every few seconds. The index is being written to continuously while being read from continuously.

This shapes the engineering more than the lookup algorithm does:

  • Positions are hot, small and ephemeral — store them accordingly rather than in your primary transactional database.
  • Update frequency is a tunable, not a constant. More frequent means fresher matching and more load, and the right balance differs by context.
  • Stale entries must expire on their own, because a driver whose app was killed will not tell you they are gone.

Correctness at the edges

Two drivers must never be offered the same ride, and a driver who has just accepted must leave the available pool immediately. That is a concurrency problem rather than a geometry one, and it is where the genuinely subtle bugs live.

Share this article

Related articles

Why We Rebuilt Fary's Dispatch Engine in Go
Engineering

Why We Rebuilt Fary's Dispatch Engine in Go

Matching riders to drivers is a latency problem before it is an algorithms problem. Here is why we moved Fary's dispatch path to Go, and what we would do differently.

October 17, 2026 · 1 min read

Why FARY Is Moving from Cross-Platform to Native Mobile Development
Engineering

Why FARY Is Moving from Cross-Platform to Native Mobile Development

Ride-hailing apps depend on more than a shared codebase. Real-time location, background tracking, navigation, and platform-specific behavior are pushing FARY toward native mobile development.

October 16, 2026 · 2 min read

What a Real-Time System Can Cache, and What It Must Not
Engineering

What a Real-Time System Can Cache, and What It Must Not

Caching driver positions is a correctness bug. Caching the map they drive on is free. The useful skill is telling the categories apart.

October 16, 2026 · 1 min read

Xsphere Logo

Product

  • Fary
  • Getbak

Company

  • About
  • CSR activity

Jobs

  • Apply Career
  • News

Blog

  • Technology updates
  • Other News

Legal

  • Privacy Policy
  • Terms of Service
Fary LogoDownload available
Download Fary on App StoreDownload Fary on Play Store