Skip to content

EngineeringMobile architecture for production ride-hailing

Engineering essay

Mobile architecture for production ride-hailing

Feature-oriented Expo architecture, background GPS, active-trip recovery, and client contracts with realtime and REST backends.

How the Rydvu driver client is structured for background location, matching UX, trip recovery, and realtime reconnect — decisions from production React Native work.

  • mobile
  • react-native
  • expo
  • realtime
  • location

Published

Problem

A ride-hailing driver client is not a CRUD app. Drivers background the phone, lose network mid-trip, and still need to appear online to matching. If the process dies, the product must restore active trip, pending assignment, or idle — not strand the operator.

Approach

The Rydvu driver app (Expo / React Native) is organized by features — location, trips, onboarding/KYC, maps, auth — rather than a flat screens dump. Client state uses Zustand for local UI/session concerns and TanStack Query for server state, with Axios for REST and Socket.IO for trip/location channels.

Background location

While on duty, the client uses expo-location (including background paths) so GPS continues when the UI is not foregrounded. Updates are paced for product realities (documented around an ≥8s class cadence) with speed handled in mph for US markets.

Coarse GPS is a product decision

Over-filtering “bad” GPS can hide drivers who are physically nearby. The platform accepts coarse GPS in defined cases so matching still discovers drivers. That is a deliberate trade-off: discoverability over perfect precision when the alternative is empty supply.

Active-trip recovery

On launch and reconnect, the client runs a recovery mutex:

  1. Restore an active trip if one exists
  2. Else restore a pending assignment
  3. Else return to idle and resume presence/polling as required

Trip sockets resubscribe after disconnect. Recovery is treated as a product feature, not an edge-case apology screen.

Matching UX

Where product requirements demanded it, the driver client used short-interval polling (documented ~3s class) against assignment state alongside realtime channels. Polling is honest physics: sometimes the simplest reliable UX wins until push paths are complete.

Trade-offs

| Choice | Why | Cost | |---|---|---| | Feature folders | Own verticals end-to-end | Discipline required to avoid cross-feature spaghetti | | Background location | Drivers stay matchable | Battery, OS permission friction, privacy UX | | Coarse GPS tolerance | Supply visibility | Slightly noisier positions | | Polling + sockets | Reliable accept UX | Extra load until fully push-driven |

Related work