Ola System Design Interview: Ride-Hailing and Maps at Scale

The driver profile and current state. Live position is not stored here; it lives in the in-memory location index. Status and city scope the matching candidate pool.

In-memory only, keyed by spatial cell so proximity queries are cheap. Overwritten every few seconds. The highest-volume data in the ride path and never written to the durable store at full fidelity.

The transactional core of a ride. Strongly consistent. State moves through requested, assigned, arriving, in progress, completed, and cancelled. route_ref links to the computed route.

Fare settlement per trip. Idempotent so a retry never double-charges. Cash is common in this market and reconciles at trip end rather than a pre-capture.

The map itself: roads, places, and points of interest, derived in the Ola Maps lakehouse from fleet telemetry and open and government sources. Continuously updated as conditions change.

Live per-segment speed estimates and closure flags, derived from vehicle pings and external sources. Feeds routing and the estimated-time-of-arrival model.

Building maps in-house versus using a third-party provider

Using a provider like a global maps API is far less work and is the right choice for most companies. Ola built its own because providers did not serve India well enough and because it was spending around 100 crore rupees a year on them. Building in-house gave control over India-specific quality and removed the cost, but it required years of work, a large data platform, and machine-learning investment. It only makes sense at Ola's scale and with a fleet that supplies the data, and it is a clear build-versus-buy case study.

Using the vehicle fleet as a sensor network versus buying map data

Buying or licensing map data is simpler, but it goes stale and does not capture fast-changing local conditions. Using the fleet, including camera-equipped scooters, as a rolling sensor network gives a continuous, fresh feed of real road data, which is a genuine advantage of being a mobility company. The cost is building the ingestion and processing to handle more than 5 million messages a second and the privacy engineering to anonymize it, accepted because fresh, India-specific data is the whole point.

In-memory geo index for driver locations versus a database

Writing every driver's few-second location ping to a durable database would overwhelm it, and nothing reads historical pings in real time. Keeping live positions in an in-memory index keyed by spatial cell gives cheap proximity queries and cheap writes, while the durable store holds only the trip record. The cost is that a node failure loses live positions, but drivers re-ping within seconds, so the index heals itself. This is the standard ride-hailing trade.

AI-first geocoding versus simple string matching

Plain string matching on addresses is easy but fails on the inconsistent, landmark-based addresses common in India. Ola built geocoding with named-entity recognition and learning-to-rank models on top of an open-source search engine, which returns the right place from an ambiguous query far more often. The cost is building and serving machine-learning models on the lookup path, accepted because address quality in the market makes the simple approach unreliable.

Separating the maps data platform from the live ride path

Combining them would be simpler to reason about, but the maps platform's heavy, petabyte-scale processing would then risk slowing down latency-critical ride requests. Keeping them separate, with the ride services consuming stable map APIs, isolates the two so the data pipeline can run at its own cadence. The cost is maintaining the API boundary and some duplication, accepted because it protects the live experience and let Ola productize the maps for outside developers.