Uber is a technology platform that connects riders with drivers and supports services including food delivery and logistics. Its familiar booking screen sits on top of a much harder problem: coordinating people, vehicles, locations, and payments while conditions keep changing.

A driver takes a different road. A rider changes the pickup point. Traffic slows near a junction.

The software has to keep up.

What is Uber’s tech stack?

There is no single, permanent “Uber stack.” Different teams use different technologies, and the platform has evolved over time.

Public engineering resources document technologies including Go, Java, React, mobile architecture tools, geospatial software, and distributed storage. These are documented parts of Uber’s engineering ecosystem, rather than a complete inventory of everything running today. Source: Uber Engineering

Mobile apps and web interfaces

Riders and drivers interact with different applications because their tasks differ.

A rider needs to confirm a destination and understand the pickup instructions. A driver needs incoming trip information, navigation, and trip controls that remain usable during a working day.

Uber’s open-source projects include RIBs, a mobile architecture framework, and Base Web, a React component library. Architecture tools help teams organise complex applications; component libraries help maintain consistent interface elements. Source: Uber’s open-source engineering projects

Neither tool, by itself, explains the entire product. The interesting part is how many systems must cooperate behind those interfaces.

You might also be interested in: Audiomack: The Technology That Built It

Backend services and data storage

A large platform separates responsibilities such as accounts, trips, pricing, and payments into services. That separation lets teams develop individual functions, although it also creates dependencies that require careful monitoring.

Uber has documented Docstore, its distributed database built on MySQL. In a 2024 engineering article, the company explained how an integrated cache supported demanding read workloads. This illustrates a recurring engineering problem: keeping data durable while making frequently requested information available quickly. Source: Uber’s Docstore engineering article

How Uber understands location

A moving dot on a map is only the visible layer.

The platform also needs ways to group locations, analyse demand, and support marketplace decisions. Uber developed H3, a hierarchical geospatial indexing system that divides the world into cells, predominantly hexagons.

Uber has described using H3 for marketplace analysis and optimisation, including pricing and dispatch work. H3 organises geographic information; it is not, on its own, the whole routing or matching system. Source: Uber’s introduction to H3

Imagine comparing ride requests around several busy streets after a concert. Geographic cells make that comparison more manageable than treating every coordinate as an unrelated point.

What developers can learn from Uber

The main lesson is not to copy its infrastructure.

A campus shuttle service probably does not need the architecture of a global transport platform. It needs reliable bookings, sensible location handling, clear notifications, and recoverable failures.

Uber’s engineering shows why technology choices should follow the problem. Start with what users need. Add complexity when the evidence justifies it.