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

Streaming Driver Positions Instead of Polling for Them

Engineering
Streaming Driver Positions Instead of Polling for Them

Location is the one piece of data in a mobility platform that never stops changing. Every active vehicle has a position that is stale within seconds, and the whole system — matching, tracking, ETAs — depends on it being reasonably current.

The naive shape is polling: each client asks for an update on a timer. It works, and it is wasteful in both directions.

What polling costs

Most polls return nothing new, so you pay the full price of a request — connection handling, authentication, serialisation — to learn that nothing happened. Meanwhile the data you do get is on average half an interval old, so shortening the interval to improve freshness multiplies the waste.

You end up choosing between stale data and unnecessary load, with no setting that is actually good.

A long-lived stream changes the shape

With a persistent stream, the connection is established once and updates flow as they occur. The per-message overhead collapses, because the expensive part happened at setup.

It also inverts control. Rather than the client guessing when to ask, the server sends when there is something to send. Freshness stops being a function of a polling interval and becomes a function of how often reality changes.

The complications you take on

  • Connections break. Mobile networks hand off between towers, apps background, devices sleep. Reconnection with sensible backoff is mandatory, not a refinement.
  • A stream holds server resources for its lifetime, which makes connection count a capacity concern in a way request rate is not.
  • After a reconnect, the client needs to resynchronise. Resuming a stream mid-flight without a reconciliation step leaves clients confidently holding stale state.
  • Load balancing long-lived connections is different from balancing short requests, and the strategy that works for one can distribute the other badly.

Not everything should stream

Position updates during an active trip genuinely benefit. A driver parked and waiting does not need the same treatment, and neither does most of the rest of the application.

Streaming is worth its complexity where data changes continuously and freshness has real value. Applied everywhere, it is just a more complicated way to make ordinary requests.

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