How UBER works: Under the hood
- Blogs, Technology
- December 11, 2020
Uber system designUber’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 AlgorithmThe 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
The Demand ServiceWhen 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 ServiceAll 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 experienceNow, 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:
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.
“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.”
Scaling the dispatch systemDispatch 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.
The use of these modified technologies significantly aids in improving system performance at Uber, a key factor to its success.
“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.”