How UBER works: Under the hood

Uber is a ridesharing software solution that completely revolutionized the dynamics of the traditional taxi industry. Established in 2009, the company rapidly gained popularity as an attractive transport alternative to conventional taxi services by offering a seamless user experience at an affordable price point.

CNBC ranked Uber as the second most disruptive company of 2018. Though it has since fallen off the list, Uber still dominates the transport market significantly.

Over the years, it has expanded exponentially, making headways into many diverse fields, introducing UberPool for ride-sharing services, offering peer-to-peer rides through UberPop, and establishing luxury travel options like UberLux. Uber is also working to develop flying taxis for fast travel.

In this article, we will gain insights into how Uber works, understanding the challenges it faces and Uber’s strategies to build a workaround for them.

Uber system design

Uber’s application is designed to look simple. But, when a rider requests a ride, an entire intricately connected backend ecosystem activates to deliver a smooth experience for its users.

Like most web-based applications, Uber started as a monolithic system architecture with a few application servers and a database. The initial system worked fine for providing services within a few cities, but, as its presence within the world swelled, Uber shifted to a service-oriented architecture, consisting of numerous services.

Basic Algorithm

The dispatch system design of Uber acts as a real-time marketplace where it matches the demands with the supply using smartphones.

So, the entire system has three broadly categorized services:

• The Demand Service
• The Supply Service
• The DISCO service

In the subsequent sections, we will talk about all these services briefly.

The Demand Service

When a rider books a ride, it gets connected to the demand service of Uber, accessing the GPS location of the rider to track the pickup point along with other specifications that the rider has requested for in the particular ride. This demand then matches with a cab within the supply pool.

The Supply Service

All the active drivers registered with Uber, periodically send their geolocation to the Supply Service with other details like the status of the drivers, for future reference. This way, whenever demand arises, the supply service has the latest information and can match with an appropriate supply.

Now that we understand the basic working of these two services, we will move on to the matching service, known as DISCO in Uber.

DISCO (Dispatch Optimization)

DISCO or Dispatch Optimization is where a series of events are activated in real-time to match demands with the supplies.

Efficient location tracking is pivotal for applications like Uber. Therefore, to enhance system output, Uber uses Google’s S2 library, which divides the entire system into small, equal-sized cells. These cells are labeled uniquely for ease of identification.

When demand arises, DISCO matches all the available supplies within the vicinity of the rider’s cell ID, matching the best possible cab with the rider based on the existing roadmap. This is critical because the road infrastructure and the traffic conditions determine the ETAs of the driver candidates. The supply service then matches the best driver available for the trip.

The DISCO algorithm aims to decrease the trip ETA by reducing:

• Overall wait time
• Driving time and distance

Uber’s challenge – Providing a seamless user experience

Now, since we have formed a basic understanding of how to design Uber backend, let’s look at the various technical challenges a real-time system faces and the workarounds Uber has found for them.

Dispatch systems like Uber are required to provide an uninterrupted and seamless user-experience. Matt Ranney, chief systems architect for Uber says:

“Another challenge is that Uber cannot afford a system failure. Ever. If a Uber customer cannot get a Uber car, then they will switch to another app. There is no brand loyalty. The systems must always work.”

To enhance system performance, Uber chooses technologies that are steady and can deliver results rapidly. It ensures that the entire infrastructure works independently of each other by carrying out extensive testing. So that, even with partial systems crashing, there is no down-time.

Scaling the dispatch system

Dispatch system-based applications like Uber require effective, scalable architectures to accommodate fast information processing in real-time. Uber addresses these challenges by using various standard technologies combined with their in-house solutions.

The dispatch system is written in Node.js, a platform built for real-time distributed systems. It has an asynchronous and event-based framework that aids the sending and the receiving of messages over WebSockets. But, according to the system architecture at Uber, Node.js and Python have performance issues therefore, Uber might switch to IO.js, a branch of Node.js, further enhancing system performance.

Uber also needed a mechanism to scale and distribute the data to multiple servers, for which it uses its RingPop technology, similar to Riak and Amazon’s Dynamo. Uber’s RingPop solution also manages cluster membership using SWIM (Scalable Weakly-consistent, Infection-style Process Group Membership Protocol).

Uber has also modified its communication channel, calling it the TChannel which is similar to Twitter’s MUX but, since Uber supports more languages compared to Twitter, it had to transform the standard RPC communication protocol to adjust to its requirements.

According to Ranney, Uber is also replacing HTTP and JSON with Thrift.

“We are even looking to replace HTTP+JSON, a typical REST API, with Thrift, as our tests are showing that it is 20 times faster. We need all the speed we can get.”

The use of these modified technologies significantly aids in improving system performance at Uber, a key factor to its success.

Data management

Real-time applications like Uber have a significant dependency on reliable data access at all times. Traditional database system architectures may act as a single point of failure for the entire system. Therefore, Uber uses Big Data stores as the infrastructure for its technologies, using tools like Redis and Postgres.

Uber considers smartphones portable minicomputers, using driver’s applications to distribute data. This way, the pressure of data replication across servers is relieved. As mentioned earlier, all the drivers check in with the supply service periodically, to receive an encrypted digest in return. If at some point, the driver does not receive a reply, it automatically connects to the backup server.

To handle these periodic driver updates, Uber works with a Kafka Cluster which logs all the incoming data traffic. This information is then sent to different worker nodes and persisted to the database asynchronously.

The way forward

Uber system design continues to evolve to match the rising user demands. It has made its mark on the transportation industry, revolutionizing the dynamics of the existing infrastructure completely.

The key to its success is performance, therefore, this is how Uber works to expand its ecosystem, providing a swift user experience. Uber’s model has set the bar high for enterprises that aim to produce fast, distributed, and scalable services for its consumers.

If you need a dispatch system similar to Uber, contact us and let our experts help you out!