rPool — Peek in to the tech stack of redBus’ ride sharing App
redBus is proud to introduce rPool — ride sharing App. We have recently launched this in 3 cities as of now — Bengaluru, Hyderabad and Pune. Please give it a try by downloading from play store here.
Background
rPool is an eco-smart option for handling all your travels to work by connecting you with fellow professional riders. As our cities are growing, increased traffic adds to the chaos and pollution.
Carpooling is the best option for socially responsible citizens. Optimising every ride, rPool makes it easy to find fellow riders for your route and pay for rides using your rPool Points. So book your ride now!
In this blog, I will try to explain the tech stack we have used and get in to some of the architecture details.
Network Diagram
The architecture broadly comprises of 3 main parts
- Native Android App on Kotlin
- Back-end REST APIs on Golang
- Data Stores — here we use a mixture of ArangoDB, Firebase and Elastic Search to power our workflows.
Some good research done in this space — this paper has been our main source of inspiration.
Native Android App
We wanted to have rPool available on our main distribution channel — core redBus App itself to users in the cities we are launching. Also, we wanted to provide that as an option in case the user is not keen on this feature. Here, from an architecture standpoint we solved this using
Android App Bundles — rPool was built as a separate module / feature and was not included in the main APK we ship. This way, we ensured the overall size of our Android App is still less. Studies have proven, the look to download ratio is correlated to the APK size. We used the Android App Bundles. More here — we got highlighted in android developer community.
Back-end REST APIs
At redBus, we have adopted Golang as one of our primary languages for development of our core APIs. Some of the concepts of Go — channels, routines are quite effective.
Data Stores
This was the interesting part of this product. What kind of data store to be used and how to model the data. We broadly divided our uses cases in to 3 categories —
- Core algorithm — Matching of drivers and passengers based on geo location, time, and few more parameters.
- Patching <> Negotiation protocol — in this phase, the driver and passengers invite each other and come to a consensus to offer / take a ride.
- Analytics, logging — for fast identification of errors and business metrics.
On #1 — We quickly realised that, the use case was a graph of customers (who are both drivers and passengers). We built on top of this fundamental layer and zeroed down to ArangoDB — a multi-modal graph DB. One of the important feature we needed was geo spatial queries. ArangoDB provides this and is quite rich in its offering.
On #2 — Here, we had 2 options, Firebase realtime DB or MQTT. We had used Firebase earlier and it was an obvious choice to integrate the notifications using FCM.
On #3 — ELK has been used across multiple products and at redBus we have been using this for quite sometime.
We believe the tech stack we have chosen will help us to scale as we iterate our product and scale to other cities.
For the greater good to the environment — Please do try out rPool for your commute in the coming days. We would love to hear from folks — please send the feedback here.
