Backend Development 9 min read

Designing a Backend System for an Uber‑Like Ride‑Hailing App with Animated Map Cars Using Go

This article describes how a ride‑hailing service built a memory‑based backend that animates cars on a map, covering challenges of sparse GPS updates, route planning with OSRM, protocol selection (UDP), data serialization (Protobuf), storage architecture, geospatial indexing with R‑tree, and the final API design.

High Availability Architecture
High Availability Architecture
High Availability Architecture
Designing a Backend System for an Uber‑Like Ride‑Hailing App with Animated Map Cars Using Go

We share the design and implementation of a backend for a ride‑hailing app similar to Uber, focusing on animating cars on the map using in‑memory storage and Go.

The initial challenge was that driver locations were reported only every 15 seconds, which caused inaccurate routes and excessive bandwidth when increasing the update frequency. A naive two‑step approach of storing coordinates and creating a separate request for animation produced unrealistic paths.

To improve routing, we integrated the OpenStreetMap Routing Machine (OSRM) to generate realistic routes and added a simple heuristic that ignores routes shorter than 20 meters, reducing jitter caused by GPS inaccuracies.

In the second iteration we moved fare calculation to the client to save server resources, increased the reporting frequency, and addressed GPS reliability issues on driver devices.

Data tracking includes driver latitude/longitude, session ID, and order information. To keep each report under 100 bytes we evaluated HTTP, WebSockets, TCP, and UDP, ultimately choosing UDP for its minimal overhead (20 bytes) and fire‑and‑forget semantics.

For serialization we compared JSON, MsgPack, and Protobuf, selecting Protobuf for its compact binary format suitable for small payloads.

The per‑report payload consists of 42 bytes of business data plus a 20‑byte IP header, totaling 62 bytes.

Storage uses Percona for persistent data, Redis for caching, and Elasticsearch for geocoding. Because large numbers of online drivers require efficient spatial queries, we evaluated KD‑tree and R‑tree, selecting the balanced R‑tree for k‑nearest neighbor searches.

An LRU cache stores the most recent N driver positions, with expiration handling for drivers inactive for 900 seconds.

The final backend algorithm steps are: use UDP to transmit data, retrieve driver info from memory (fallback to Redis), validate data, store driver in memory, initialize LRU if needed, and update the R‑tree.

We expose HTTP endpoints to return nearby drivers, delete drivers by plate or session ID, and fetch trip or driver details.

In conclusion, the system combines UDP + Protobuf for low‑bandwidth transmission, in‑memory storage with an R‑tree for fast spatial queries, an LRU cache for recent positions, and OSRM for map matching, achieving a functional animated‑car feature for the ride‑hailing app.

backendGoProtobufRide-hailingUDPmap animationR-tree
High Availability Architecture
Written by

High Availability Architecture

Official account for High Availability Architecture.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.