Uber Tech Stack

Uber's public engineering material describes a stack shaped by one hard requirement: matching riders, drivers, maps, pricing, payments, and support workflows in near real time across many cities. No single product or framework makes that work. The architecture is a collection of specialised layers that reduce latency on the customer path while still feeding large internal data and operations systems.

It is also worth reading any such stack diagram as a snapshot, not a permanent truth. Uber changes tools over time, and public posts usually describe parts of the platform rather than a single canonical stack.

Client and edge layer

On the client side, Uber has written about web applications built with Fusion.js and mobile architectures based on RIBs. The important idea is not the names themselves. It is the separation of presentation, business flow, and service communication. A ride request is a multi-step interaction with location updates, fare estimates, identity checks, and payment state. Clients therefore need structure that keeps UI logic from collapsing into network-callback sprawl.

At the edge, gateway and service mesh components sit between clients and internal services. Public descriptions mention NGINX-based gateways, gRPC and QUIC for efficient client-server transport, and Apache Thrift for interface definition in parts of the estate. This layer handles cross-cutting concerns such as routing, authentication, rate limits, and protocol translation. That keeps product teams from rebuilding the same networking logic service by service.

Service layer and coordination

Behind the edge sits a large service estate. Public Uber material has referenced Java and Spring Boot for many backend services, configuration systems such as Flipr or UCDP, and asynchronous workflow tooling such as Cadence. That combination makes sense for a company with many independently deployable services.

Configuration systems matter because operational change often happens faster than code deployment. A feature flag or a policy value can change matching logic, surge behaviour, or regional rollout without rebuilding the service. Workflow systems matter because many business processes are long-running and failure-prone. Payment retries, document verification, and support flows need state that survives service restarts and partial outages.

Data stores for different workloads

A ride platform does not have one database problem. It has many. Public descriptions have referenced strongly consistent operational storage, relational engines such as MySQL and PostgreSQL, RocksDB-based internals, and geospatial systems such as H3. The pattern is clear: choose storage by workload.

Transactional systems need correctness and predictable writes. Geospatial indexing needs fast proximity operations. Logs and events need durable append behaviour. Analytical systems need cheap scans across large time ranges. Trying to force all of those patterns into one database would either hurt latency or make operations unmanageable.

Streaming, analytics, and observability

Uber's public stack also highlights Kafka, Flink, Spark, Hive, Hudi, Parquet, Alluxio, Pinot, and AresDB. This points to a second architecture running alongside the transactional one: a data platform for event transport, batch and stream processing, experimentation, and operational analytics.

That split is important. The rider app needs a quick answer now. The company also needs fraud analysis, demand forecasting, dispatch optimisation, and post-hoc reporting across enormous historical datasets. Those goals pull the storage and compute layers in different directions, so separate systems are the practical answer.

Platform and delivery tradeoffs

The overall stack suggests heavy investment in internal platform engineering. Monorepo workflows, observability systems, deployment tooling, and shared runtime conventions reduce local reinvention. The tradeoff is platform complexity and organisational dependence on internal tooling quality.

So the real story of Uber's tech stack is not a list of fashionable products. It is a workload-driven architecture: low-latency user journeys at the edge, many services in the middle, specialised data systems underneath, and a large platform layer that keeps the whole estate operable at company scale.