redBus launches ridesharing with live location tracking

This is a guest blog by Phaneesh Gururaj, Vice President–B2C Engineering at redBus

redBus is the world’s largest online bus ticket booking service trusted by over 20 million users. In June 2019, we launched a ridesharing service rPool (bike-pool and car-pool) for our users to commute smartly where they can reduce traffic and also save money on their daily commutes. Verified redBus users can share their car rides with each other in a privacy-protected manner and make their daily commute fun. This service is now live in three Indian cities–Bangalore, Hyderabad and Pune.

Live location tracking is a foundational part of rPool

The ride giver (driver) and ride seeker (passenger) are matched using their live location and mutual destination. Once matched, live location tracking is required for the passenger to track the driver for a smooth pickup experience. Once the ride begins, location helps track the miles driven together, which helps earn points. Deviations from route would also be monitored in real-time and notified to users. A secure record of the rides would be stored in our system so we can use this data to ensure safety and efficiency of the ride-sharing network.

Here is a video of the experience we built.

Live bus tracking has been part of core redBus

redBus has been serving real-time location alerts to passengers and bus operators for a while now. So we know a thing or two about live location tracking. But exploiting the device location through the app to provide live location tracking is a different challenge from vehicle connected GPS. Anyone who has spent a reasonable time on this technology would understand that you need to handle many nuances to get reliable tracking information. Experiments help us proto-type in the lab and test with a dozen users, but taking the feature to production and then scaling it up requires significant engineering investment. After multiple experiments, we decided to look at developer libraries to build with.

How we discovered HyperTrack

We read about HyperTrack in a blog post talking about real-time live location tracking in 2017. It was quite easy to set up. We tried it on two different experimental projects. However, during this time we got a good understanding of HyperTrack’s capabilities–

• Background service reliability on various devices
• Battery drain while tracking
• Controls it provides to set trips with ETAs
• Latency of locations from device to our app
• Level of support provided by the team.

Finally, when we were building rPool, it was quite clear that we would use HyperTrack to build it with.

Our journey with the platform

Getting the SDK into the Android app was easy. There were some new learnings due to ProGuard blocking the tracking and dependencies on Android X in the HyperTrack SDK. However, the support was fast and accurate, and we were able to resolve and move past these. To start, we ingested live location data to our servers through Webhooks so we could control the app experience in our tight delivery timelines to go to market. We used our own mechanism to get this location data from our servers to our app clients over WebSocket (see Phase 1).

After gaining confidence in the HyperTrack data over a couple of months in production, we were ready to take the next step and go serverless for live location with HyperTrack (see Phase 2). We started using the HyperTrack Views SDK on Android for the passenger to get location updates directly from the HyperTrack server to our app instances. We still controlled the visual experience in the app, and Views provided callbacks to give us the data in the app. Views uses GraphQL to manage data query and subscription from the HyperTrack servers to the client, which gives us confidence in their ability to scale to our volumes.

Using Trips to offload compute and 3rd party map APIs

In addition, we started using the Trips feature to set destination and get real-time ETAs & estimate routes. Trips offers a nifty summary and a cool replay feature that we can go back to on the dashboard in case a dispute comes up, or we detect potential fraudulent activity on the platform.

What worked for us

Our team loves the fact that we control the extent to which we use HyperTrack in production, and the phases in which we roll out. We had launched rPool on Android only, and HyperTrack aligned their timelines for Views SDK on iOS with the rPool iOS release so we were unblocked.

HyperTrack helped us get to market much quicker than we would on our own, and we count on them to stay current with the OS updates and latest technologies so our engineering resources can focus on what matters most to our business.

Due to an integration gaffe in our first release, we flooded HyperTrack servers with events from millions of users of the redBus app. We were surprised that HyperTrack servers were able to deal with that traffic with no prior heads up or issues. We loved the attitude of their team that despite incurring the extra cost, thanked us for load testing the system in the wild and helping improve their platform design to account for such scenarios. It feels like we are working with a solid platform that we can count on to scale.

Our team counts on HyperTrack. While we wish they delivered all the features we want by tomorrow <kidding>, we understand that HyperTrack v3 is being built thoughtfully with focus on quality. We consider them our friends in the live location business and can get back to work in making our rPool users happy, and scaling up to a larger number of cities and app users.

Go give rPool a spin through your redBus app (Android, iOS) when you are in Bangalore, Hyderabad or Pune. Go give HyperTrack a spin if you are building an app with live location tracking.