Uber API Design Decisions

The API design for the Uber system is tricky because it has multiple services interacting under the hood to perform the desired functionalities. It involves a significant level of communication between the different types of users and the back-end services. Moreover, we also request data from third-party services like Google Maps. Therefore, we‘ll observe substantial technical considerations such as choosing an architectural style, data formats, and the protocol to communicate between the clients and services. Let's start the discussion with the design overview and then move on to the workflow and technical design considerations.

Design overview

The high-level design of Uber consists of mainly three types of services defined below:

1. Back-end services: These services perform the core operations of handling requests from clients (riders and drivers), such as requesting a ride, maintaining the trip, tracking the locations of the driver and the rider, and so on.

2. Supporting services: The Google Maps service has a key role in providing an effective Uber service. It is responsible for the provision of the rider and driver's location. Other than that, the payment gateway service reliably transfers charges from the rider to the driver's account. The chat service allows the rider to chat with the driver until the driver arrives at the rider's pickup location.

3. Persistence layer: This layer stores various types of data for a variety of purposes. Other than storing user data, it maintains a history of different rides and completed trips to provide accurate and low-latency service by learning over time through technologies like machine learning (ML).