Examining the Uber Architecture

Read at your own pace. Code execution, quizzes, progress tracking, and the AI tutor are available in the interactive view with JavaScript enabled.

Introduction

This tutorial introduces Uber's journey from a Monolithic architecture to a Service-Oriented Architecture and their use of the Google S2 Library to model maps and location data. It explains how Uber has been able to improve performance by replacing their architecture with DISCO/Dispatch optimization and how they use latitude, longitude coordinates, and a specific radius to identify regions. We will also explore how Uber has transitioned from a Monolithic architecture to a microservice architecture and how they are able to achieve coverage of any arbitrary shape using the Google S2 Library.

Uber works by prompting a user to request a ride and provide their current location/destination. A certified driver nearby will come to the user's location and drive them to their requested destination. In the early stages, the Monolithic architecture model was followed to build Uber. Like any other ordinary application, it contains frontend and backend services and a single database.

Uber Architecture

Uber has used Python frameworks along with SQLAlchemy to provide an ORM-layer to the database. This architecture was acceptable during the early stages of the company when the client base was small, but as Uber grew, the company began facing problems regarding performance and maintenance.

CONTINUE WITH ALGODAILY PREMIUM

Keep going with the complete tutorial.

Unlock the remaining explanations and exercises, alongside the full learning library.

Explore Premium →

Open interactive view →