Skip to main content
Xsphere
  • ပင်မ
  • ကျွန်ုပ်တို့၏ လက်ရာများ
  • ကျွန်ုပ်တို့အကြောင်း
  • ဘလော့ဂ်
  • အလုပ်လျှောက်ရန်
  • ဆက်သွယ်ရန်
Xsphere
  • ပင်မ
  • ကျွန်ုပ်တို့၏ လက်ရာများ
  • ကျွန်ုပ်တို့အကြောင်း
  • ဘလော့ဂ်
  • အလုပ်လျှောက်ရန်
  • ဆက်သွယ်ရန်

October 17, 2026 · 2 min read

Why We Rebuilt Fary's Dispatch Engine in Go

Engineering
Why We Rebuilt Fary's Dispatch Engine in Go

Every ride-hailing platform eventually runs into the same wall. The matching logic that felt instant with a few hundred drivers starts to drag once a city fills up, and the slowdown shows up in the worst possible place: the seconds a rider spends staring at a spinner, deciding whether to close your app and open someone else's.

The problem was never the algorithm

Our first instinct was to make the matching smarter. Better scoring, tighter geofences, more signals per driver. That work mattered, but profiling told a less flattering story. Most of the time a rider waited was not spent deciding which driver to send. It was spent waiting on serialisation, on database round trips, and on a request path that did too much work per call.

Dispatch is a soft real-time system wearing the costume of a CRUD app. Once we started treating it that way, the bottlenecks were easier to find.

What Go bought us

We moved the dispatch path to Go for reasons that were boring and practical rather than ideological:

  • Predictable latency under concurrent load, without tuning a garbage collector for every release.
  • Goroutines that let us fan out driver lookups and collapse several sequential round trips into one parallel step.
  • A deployment story simple enough that a single static binary runs the same way on a laptop and in production.
  • A type system strict enough to make the hot path hard to accidentally slow down.

What we would do differently

We rewrote more than we needed to. The dispatch loop genuinely benefited from the move, but we carried along adjacent services that were never the problem, and we paid for that in review time and migration risk.

The lesson we took into later work: profile first, carve out the smallest surface that actually hurts, and leave everything else alone until it earns the rewrite. A rewrite that touches less is a rewrite you can ship.

Where this leaves us

Dispatch is no longer the part of Fary we worry about during peak hours, which means our attention has moved to the parts that now matter more — routing quality, driver supply, and the long tail of edge cases that only a live city produces.

Share this article

Related articles

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

Streaming Driver Positions Instead of Polling for Them
Engineering

Streaming Driver Positions Instead of Polling for Them

Thousands of vehicles reporting location continuously. Why request-response is the wrong shape for that problem, and what changes when you stream.

October 16, 2026 · 1 min read

Xsphere Logo

ထုတ်ကုန်များ

  • Fary
  • Getbak

ကုမ္ပဏီ

  • ကျွန်ုပ်တို့အကြောင်း
  • ကူညီရေးလှုပ်ရှားမှုများ

အလုပ်အကိုင်

  • အလုပ်လျှောက်ရန်
  • သတင်းများ

သတင်းအချက်အလက်များ

  • နည်းပညာသတင်းအချက်အလက်များ
  • တခြားသတင်းများ

ဥပဒေ

  • ကိုယ်ရေးအချက်အလက် မူဝါဒ
  • စည်းမျဉ်းစည်းကမ်းများ
Fary Logoဒေါင်းလုပ်ဒ်ဆွဲနိုင်ပါပြီ။
Download Fary on App StoreDownload Fary on Play Store