Guides

Uber Architecture Explained: How Uber Matches Riders and Drivers

By Ravindra Bagale, AWS & DevOps trainer · LinkedIn · Published: 18 October 2026 · Last updated: 18 October 2026

Short answer: Uber runs about 4,000 microservices, grouped into domains and layers (its DOMA design, 2020). Since 2024 they run on Kubernetes: more than 50 compute clusters across Uber's own data centres and the cloud providers Oracle Cloud and Google Cloud (2025). Services are deployed about 100,000 times a day. Much online data lives in Docstore, Uber's database built on MySQL, with an integrated Redis cache called CacheFront serving over 150 million reads per second (2025).

Suppose you book an Uber auto in Bengaluru

You open Uber at Koramangala, choose Uber Auto and tap Confirm. In simple terms:

1. Your app sends the request to Uber's backend, which is made of thousands of services.
2. Services in different domains (riders, pricing, matching, maps, payments) work together.
3. These services run as containers on Kubernetes clusters in Uber's data centres or on Oracle Cloud and Google Cloud.
4. Trip and user data is read from Docstore; most reads are served from the CacheFront Redis cache, with a hit rate above 99.9%.
5. When data changes, Flux reads MySQL binlogs and refreshes or invalidates the cache, usually in under a second.
6. A driver accepts, and both apps update live.

What architecture style does Uber use?

Uber is one of the best-known microservices companies, and it has written about both the benefits and the pain.

1. Domain-oriented microservices (2020): at about 2,200 critical microservices, Uber grouped services into domains, with clean interfaces (gateways) and layers that limit which domains can depend on which.
2. Kubernetes everywhere (2024 to 2025): stateless services moved from Apache Mesos to Kubernetes in 2024; batch and storage are converging too.
3. Federation layer "Up": developers manage service lifecycles through Up, which places services onto clusters.
4. Scale: each cluster has about 5,000 to 7,500 hosts and 250,000 cores; services use about 3 million cores in total.

Uber architecture diagram (public parts)

This diagram shows only what Uber or its partners have shared publicly. Press Play to follow a request step by step.

What does Uber use? Main technologies

Which cloud provider does Uber use?

Uber uses a hybrid, multi-cloud setup. As of 2025 the Container Platform team manages 50+ clusters across regions and zones in on-prem data centres and cloud providers Oracle Cloud and Google Cloud.

How does Uber keep 150 million cached reads per second fresh?

In 2025 CacheFront keeps a huge Redis cache consistent with the database:

1. Reads first try Redis; missing rows are fetched from the storage engine and written back to Redis.
2. Writes now return the exact set of changed row keys and a commit timestamp. The query layer then overwrites those cache entries with invalidation markers, either before replying (for read-your-own-writes) or in the background.
3. Flux still tails MySQL binlogs and refills or invalidates the cache within about a second.
4. TTL expiry is the third safety net.

Using three ways together let Uber raise TTLs up to 24 hours while keeping hit rates above 99.9%. CacheFront's footprint grew almost four times in a few years.

How big is Uber's Kubernetes platform?

The 2025 migration numbers: numbers: 50+ clusters, each with about 5,000 to 7,500 hosts, 250,000 cores and 50,000 pods; about 4,000 services using about 3 million cores; 100,000 deployments a day, leading to 1.5 million pod launches a day at 120 to 130 pods per second in a single cluster.

How it started: from monolith to thousands of services (before 2020)

1. Uber started with a monolith and moved to microservices as it grew fast.
2. In 2016 Uber built Schemaless, a scalable datastore built on MySQL.
3. Stateless services ran on Apache Mesos (with Uber's Peloton scheduler for batch) for years before the Kubernetes move.
4. By 2020 the number of microservices made even small features hard to build, which led to DOMA.

How does Uber store data?

1. Docstore: Uber's online database; a stateless query engine layer over stateful storage engine nodes on MySQL.
2. CacheFront: Redis cache built into Docstore's query layer, with TTLs up to 24 hours and hit rates above 99.9%.
3. Big-data storage details are outside these posts and not covered here.

How does Uber monitor its systems?

1. CacheFront includes a Cache Inspector that measures how stale cached data is (2025).
2. Deploys are tracked across 100,000 deployments and 1.5 million pod launches per day.
3. Uber's company-wide metrics and alerting stack is not publicly shared.

If we built an app like Uber on AWS (illustrative)

Suppose you want to build "SawariGo", an auto-rickshaw booking app for a city. Here is a simple AWS layout.

1. Network: VPC, subnets, route tables, gateways

1. Create one VPC with CIDR 10.0.0.0/16 in the Mumbai region (ap-south-1).
2. Use two Availability Zones (A and B), so one AZ failing does not stop the app.
3. In each AZ make three subnets: public (load balancer, NAT gateway), private app (your code) and private data (databases, cache).
4. Attach one internet gateway (IGW) to the VPC. Public route table: 0.0.0.0/0 → IGW. This route is what makes a subnet public.
5. Private app route table: 0.0.0.0/0 → NAT gateway, so servers can download updates but nobody can connect in from the internet.
6. Private data route table: only the local VPC route. Use VPC endpoints to reach S3, DynamoDB and SQS without going over the internet.

2. Compute: where the code runs

1. ALB with WebSockets.
2. Services on EKS, grouped by domain.
3. Trip events through SQS or Kinesis.

3. Storage and databases

1. ElastiCache for Redis with geo commands for nearby drivers.
2. DynamoDB for live trip state.
3. Aurora for accounts and trips; S3 for documents.

4. Monitoring

1. CloudWatch alarms on matching time.
2. X-Ray traces between services.

Request flow diagram

Press Play. The numbered list below the diagram lights up with each step.

Uber versus our AWS design