Building a Real-Time Taxi Booking App with Live Maps

The map is the product surface, so the SDK choice constrains everything drawn on top of it. We evaluated react-native-maps with Google Maps against alternatives like Mapbox.

Google Maps won on three practical grounds: faster setup, better documentation, and stable performance for standard taxi use cases. None of those are glamorous, and that was the point. This app needs a map, a moving marker, and a route line. It does not need custom tile styling or offline vector rendering, and picking the SDK with the deeper feature set would have meant paying integration cost for capability the product never uses.

react-native-maps renders through the platform's native map view rather than wrapping a web map, so markers and polylines are drawn by the native SDK on both iOS and Android. That mattered later. By the time the performance work in step 04 started, marker drawing was already native, which meant the remaining cost sat in React re-rendering the component tree rather than in the map itself.

The decision also settled the routing provider. Displaying Google's map while routing against a different road graph would mean reconciling two sets of geometry, so the Directions API integration in step 03 followed from this choice rather than being made independently.

Polling every five seconds sets a floor on latency that no amount of tuning gets under. The rider's app cannot learn about a position change until the next scheduled request, so average staleness is half the interval and the worst case is the whole of it. The measured four to five second delay was the floor working as designed, not a bug in the implementation.

Shortening the interval does not fix it, it just moves the cost. Halving the interval halves the delay and doubles the request count, and the request count was already the problem: roughly sixty per minute per user, almost all returning a position that had not meaningfully changed.

We replaced the loop with a persistent WebSocket connection handled by a Node.js service. The driver's app pushes position updates as they happen, and the server fans them out to the riders subscribed to that ride. Communication is bidirectional over the same connection, so ride state travelling the other way does not need a second mechanism.

The inversion is the whole point. Polling asks 'has anything changed' on a schedule. A socket says 'this changed' when it does. Redundant requests were not reduced here, they stopped existing, because there is no longer a request that can be redundant.

Tracking the driver's position answers where they are. Riders also want to know when the car arrives, and that needs a route.

We integrated the Google Directions API to fetch the optimal route between the driver and the pickup point, drew it on the map as a polyline, and updated it as the driver moved. The arrival estimate comes out of the same response, so the line on the map and the number beside it always describe the same route.

Updating that route naively is expensive. Re-fetching directions on every position update would have reintroduced exactly the request volume step 02 removed, on a more costly endpoint. So route re-fetching runs on a threshold rather than a timer. While the driver is following the route already drawn, the existing result stays valid and is served from cache. A new call goes out when the driver has deviated enough that the drawn route no longer describes where they are going.

That is the difference between treating directions as a subscription and treating them as a fact with a defined invalidation condition. The polyline redraws continuously from data already on the device, and the network call happens only when the underlying answer has actually changed.

With updates arriving in under a second, the render path became the bottleneck. Every incoming position triggered a state update, and every state update re-rendered the marker set, including every marker that had not moved.

All marker components are memoized, so a position update re-renders the marker it describes and leaves the rest alone. On a map showing a driver, a pickup point, a destination, and a route, that turns a full re-render into a single component update.

Location updates are also throttled to every one to two seconds rather than being applied continuously. That reads like a step back from a sub-second socket, and it is not. The socket removed the latency floor; throttling controls how often that fresh data is committed to React state. The device receives updates as they arrive and redraws on a controlled cadence, which is what keeps marker movement smooth rather than stepped.

The combination is what produces the result. Sub-second data with unthrottled rendering was fast and janky. Sub-second data with memoized markers and a throttled commit is fast and smooth: 60fps marker animation, no visible lag.

Continuous GPS at full accuracy is the most expensive thing a location app does, and for most of a ride it is unnecessary. A rider waiting on a driver who is eight minutes out does not need metre-level precision refreshed continuously. A rider being picked up right now does.

So tracking adapts to ride state. GPS accuracy drops when the app is idle, and the tracking interval scales with what is happening: coarser and less frequent when nothing is imminent, tighter as the driver closes in and during the ride itself. The device spends its power budget on the parts of a ride where precision changes what the rider sees.

This is step 03's principle applied to the sensor instead of the network. Both replace a fixed schedule with a condition, and in both cases the condition is whether the thing being tracked has changed in a way that matters. Estimated battery reduction is 20 to 30%.

Battery is also why the polling architecture was unsalvageable. Polling keeps the radio active on a timer regardless of ride state, so no amount of GPS tuning would have helped while the network layer was waking the device sixty times a minute anyway.