Case Study

Namba Taxi:
Modernising
transport

The system that took urban transport in Bishkek, Kyrgyzstan to the
next level in 2013 by making taxi ordering fast, efficient and
convenient and continues to function today.

Namba Taxi (now BiTaxi) is a leading ride-hailing service in Bishkek, Kyrgyz Republic. Mad Devs developed software for the service from scratch to revolutionise the way people move around in a modern city. The project was doubly challenging: we needed to develop complex technological solutions and create user experiences engaging enough to make people change their behaviours. It was Mad Devs’ longest-running project so far as we worked with Namba Taxi from 2013 to mid-2020. Together, Mad Devs and Namba Taxi achieved the ultimate goal: let the residents of Bishkek quickly get around the city with convenience.

from 2013 to mid-2020

team members

~700

drivers

~10,000

trips per day

Why the city needed a better taxi service

Before Namba Taxi, people in Bishkek had two options if they needed a taxi: a private driver or a dispatcher-operated service. Arbitrary rates and the need to hitchhike made the service unreliable and inconvenient for a modern city resident who wants to plan their schedule and make it to places on time. Dispatcher-based systems, in turn, lack efficiency: the intermediary between the passenger and the driver makes the whole process overly time-consuming.

Automation of the driver-passenger interactions is what Namba Taxi decided to pursue. Mad Devs’ mission is to automate as many interactions as possible: we want to let machines do everything that they can do better than humans. Namba Taxi wanted an automated, next-generation, Uber-like transportation solution. We undertook the challenge of developing this software. We undertook the challenge of developing this software and started in 2013.

Benefits of Namba Taxi

Sharing economy

Namba Taxi was one of the first companies in Central Asia to join the sharing economy. If calling a cab is simple enough, people will prefer it to owning a car. This creates a city with fewer cars and a more efficient distribution of resources, making urban development more sustainable.

Transparency

Operators and passengers can track cab rides in real time. The mobile applications we developed for this project enable convenient communication and feedback. Riders can order a taxi with just a few taps, and both riders and drivers can see the progress of a ride.

Quick service

A Namba Taxi cab arrives within 7 minutes. A smart itinerary planning system drastically reduced waiting time by eliminating much of the manual work done by dispatchers. The system’s scalable, failproof architecture can handle up to 700 drivers on the line, 6,000 queries per second, and 10,000 orders a day.

Mobile transformation

With Namba Taxi, drivers and passengers can do everything on their mobile devices. When development started in 2013, passengers had to make a phone call to order a cab, effectively turning taxi services into call centres. Namba Taxi changed this paradigm.

Quality control

With an automated ordering system, Namba Taxi can focus on improving the passenger experience. The company monitors a multitude of performance indicators, including each car’s technical condition and even drivers’ health, to ensure more enjoyable cab rides.

How we did it: Requirements and limitations

Software requirements were prepared in close collaboration with the customer and with emphasis on business goals. Our rule is to prioritise end users’ experience: we focus on how our product will be helpful instead of focusing on how convenient it will be for us to develop it. Discussions and analysis helped identify eight main requirements.

Minimal alterations to the workflow: Switching to a new software system should be smooth and painless for the company and the drivers.

Scalability: To allow the system to grow in the future, we planned to implement an architecture that can be modified and expanded.

Support for Android devices: We needed to promote the transition to more convenient, modern technologies.

Real-time updates: We focused on reducing waiting times as this parameter is crucial to the passenger experience.

High fault tolerance: Demand for taxi services can have dramatic ups and downs (e.g., when it starts to rain), so the system should have failover capability.

Agile development: If the customer’s requirements change during development, we can introduce new technologies as needed.

Compatibility with navigators: Not everyone had switched to mobile apps when the project started, so we had to ensure integration with drivers’ devices

Safe transition: Moving from old software to new software must not paralyse the business’s continuous operation or reduce the quality of service.

Identifying limitations was the next step. Internet service was expensive in 2013, so we needed a highly efficient system that delivers proper performance with as little mobile traffic as possible. The goal was to reduce the costs for the drivers and the passengers who use the mobile app. We also kept in mind the customer’s business costs: server resources, for instance, were limited.

We chose the iterative approach that delivers a complete, functional product for a specific business process after each iteration.

Oleg Puzanov, CSO at Mad Devs

Building a fault-tolerant architecture

We invested much effort in the architecture because we wanted to do things right, right from the start. A taxi service needs a highly flexible and failproof system to rely on. The numbers of requests to process and operations to run can vary remarkably depending on both regular factors, like rush hours, and unpredictable ones, like the weather. Here is the relevant data collected during our work on the project.

3,500

requests processed per second

20 ms

at most it takes to send responses to drivers

2.5 ms

at most it takes to send responses to dispatchers

Given the requirements and the limitations, we decided to implement a one-core architecture using multiple technologies and open-source software with no OS- or device-related restrictions.

Ruby has Ruby-SMPP that deals with the SMPP protocol to receive and send text messages. We needed Node.js because of Socket.IO that enables real-time messaging. Turning to open-source software and choosing to develop a web application meant that staff could work remotely and it was no longer necessary to spend money on switching equipment or licences. So we could attract more customers.

Implementation

To build the backend part of the web application, we chose Django as a flexible and secure development tool that provided for efficient client-server interactions in a request-response mode. Due to its high scalability, Django could easily cope with heavy traffic processing multiple requests from the users and quickly responding to them. As a result, the application could run smoothly even during high-demand periods.

Drivers

Twisted was another component that we added to our web application’s architecture to make the remote system’s communications faster and more reliable. As a scalable event-driven engine, Twisted can handle numerous requests simultaneously. SMS notifications for clients were sent to drivers, i.e. our Twisted sent requests to Django through a Ruby daemon and then processed requests through the SMS provider’s centre (SMSC).

SMS orders

Instead of making phone calls, clients could now place an order by a text message. The messages they sent reached the SMSC first. After that, we picked up the message using a Ruby daemon and made a POST request. We chose the POST request method as a secure way of transmitting sensitive data provided by the app users. Finally, the POST requests were sent to Django that processed the received messages.

Dispatcher service

Operators’ two work processes were to accept orders and to handle telephone calls. All orders come to Django via POST requests; Django then saves a Percona order and sends it to a specific Redis channel that is listening to Node.js. Next, the information is sent to the operators’ broadcast channel.

The simplest part of our system automates managers’ work. The core components here are Django and Percona—an open-source database management system. This helps managers to deal with large amounts of information, such as orders, client and driver databases, in a prompt and easy manner. Django collects data from Percona and sends it to Excel or to the browser.

Transition

Moving to the new software was difficult, and we learned many lessons from it. The transition took seven days and taught us to make better use of our frameworks and to create more realistic, reliable load tests. Admittedly, we lost about 8% of orders that week, but we brought the waiting time for passengers from 8 down to 5 minutes.

Further growth

Quick growth ensued, presenting a new round of challenges. We needed to constantly introduce changes and improvements to ensure that the system could handle the load. For example, we used Sentinel at some point to provide fault tolerance for Redis. Later, we switched to Asterisk 11.5 as the telephone exchange to manage GSM gateways and providers. When we discovered that Asterisk had trouble bridging audio between devices, we moved to FreeSWITCH. We were constantly perfecting the system.

Mobile applications

We developed mobile applications that can handle the full range of functions a taxi service needs. Passengers, drivers, and operators interact through a thoroughly automated environment. Passengers order a cab with just a few taps, drivers can accept orders within seconds, and all journeys can be tracked in real time.

Ariadna: Data geocoder

Ariadna is an in-house developed, open-source geocoder based on ElasticSearch that uses OpenStreetMap. The tool searches for coordinates using the names of places and synonyms. It can find crossroads and addresses within a certain radius. It does reverse geocoding and updates automatically as it receives new data from drivers.

One of the most challenging things in the project was to enable human-friendly search on the map. Ariadna was a unique solution that handled the task.

Alexander Edakin, Backend Developer

The overall interaction scheme

The result was a complex yet reliable system. It features six roles (Operator, Passenger, Partner, Driver, Manager, and Corporate Client), and here’s how interactions among apps and third-party software go: