Uber's Architecture: From Monolith to Microservices at Scale

Uber did not start with microservices. Like most startups, it began with a simple monolith: one codebase, one database, deploy everything together. This approach worked fine when the product was new and the team was small. But growth has a way of exposing architectural sins.

I keep coming back to Uber’s story because it illustrates something important about distributed systems. The challenges are not primarily technical. They are organizational. The architecture you end up with says more about your team’s structure than your engineering preferences.

The Monolith Era and Its Discontents

Uber’s original architecture was, by modern standards, unremarkable. A backend for the rider and driver apps, a database to store everything, and a straightforward request-response model. The code lived in a single repository. Deployments involved the whole stack.

This worked until it did not.

As Uber expanded globally, several problems became harder to ignore. Every code change required testing the entire system. Deployment windows stretched hours long because unrelated features had to ship together. Teams stepped on each other constantly. A pricing bug could delay the dispatch system while engineers hotfixed the whole platform.

The incident that usually gets cited is the 2010s expansion phase when Uber went from a few cities to dozens. Different teams needed different release cycles. The monolith made that impossible without a lot of coordination overhead.

The real pain point was not any single issue. It was the compounding effect of coupling. Business logic, data access, and state management all tangled together. Scaling one component meant scaling everything. If the database was under load, the API servers had to scale too, even if they were idle.

Decomposition Strategy

Uber’s move to microservices followed a pattern I have seen at other companies, though their implementation was more thorough than most. The guiding principle was boundaries around business capabilities.

Each service got its own domain. Pricing logic went into a pricing service. Matching drivers with riders became the dispatch service. Payments, user accounts, driver profiles, and receipts each became separate units. These services communicated through defined interfaces, usually REST or thrift.

The decomposition was not random. Uber organized around the minimum units of business logic that made sense independently. A pricing change should not require a dispatch deployment. A new payment method should not mean retesting rider matching.

Here is the high-level architecture as a Mermaid diagram:

graph TB
    subgraph "Client Layer"
        RiderApp[Rider App]
        DriverApp[Driver App]
    end

    subgraph "API Gateway"
        Gateway[API Gateway]
    end

    subgraph "Core Platform Services"
        Dispatch[Dispatch Service]
        Pricing[Pricing Service]
        Payment[Payment Service]
        User[User Service]
        Driver[Driver Service]
    end

    subgraph "Supporting Services"
        Notification[Notification Service]
        Map[Map/ETA Service]
        Auth[Auth Service]
        Audit[Audit/Logging Service]
    end

    subgraph "Data Layer"
        DB1[(PostgreSQL)]
        DB2[(MySQL)]
        DB3[(Cassandra)]
        Cache[(Redis Cache)]
    end

    subgraph "Coordination Layer"
        RingPop[RingPOP]
        TChannel[TChannel RPC]
    end

    RiderApp --> Gateway
        Gateway --> Dispatch
        Gateway --> Pricing
        Gateway --> User
        Gateway --> Driver
        Gateway --> Payment

    Dispatch --> Pricing
        Dispatch --> Map
        Driver --> Auth
        Payment --> Audit

    Dispatch --> Cache
        User --> DB1
        Driver --> DB2
        Payment --> DB3

This diagram leaves out a lot of detail, but it captures the core structure. The API gateway routes requests to specialized services. Services call each other through remote procedure calls. Data stays isolated per service.

Core Services Deep Dive

Dispatch

The dispatch service is Uber’s heart. It matches riders with drivers in real time. When you open the app and request a ride, dispatch figures out which nearby drivers can fulfill the request, applies pricing rules, and sends the match downstream.

The tricky part is latency. A dispatch decision has to happen in seconds, not minutes. This means dispatch keeps very little state locally. It calls out to other services for pricing, ETAs, and driver availability, but it makes the final decision fast.

Uber has written about using a technique called batch optimization for dispatch. Instead of processing one request at a time, the system batches nearby requests and solves the assignment problem for the whole batch simultaneously. This improves utilization but adds complexity to the code path.

Pricing

The pricing service handles surge pricing, fare estimation, and final bill calculation. It receives a request with trip details and returns a price or a multiplier. The complexity here is in the rules engine.

Surge pricing at Uber is not a simple multiplier. It factors in historical demand, real-time supply, location, vehicle type, and a dozen other signals. The rules live in a configuration system that pricing reads on every request. Caching helps, but stale pricing data creates user-visible bugs, so the cache TTL is short.

What interests me about pricing is the balance between flexibility and consistency. The service needs to apply the same rules across all regions while allowing regional overrides. A configuration change in one city should not break another.

Payment

Payment processing involves capturing funds, handling fees, splitting payments between Uber and drivers, and managing disputes. This is sensitive code. A bug here means real money problems.

Uber’s payment service operates differently from the rest of the platform. It leans toward synchronous, reliable communication. While other services might tolerate eventual consistency, payment cannot. If a charge succeeds, the record must reflect that immediately.

The payment service also handles the financial audit trail. Every transaction gets logged immutably. This creates a high write volume. Uber uses Cassandra for this workload, which handles the write throughput better than a traditional RDBMS.

User and Driver Services

These two services manage accounts and profiles. User handles riders: registration, authentication, preferences, and history. Driver handles driver accounts: documents, vehicle information, ratings, and earnings.

Both services see high read volume. User profiles get fetched on every app open. Driver information loads when dispatch prepares a match. Caching is aggressive here. Most reads hit Redis before touching the primary database.

The interesting constraint is data freshness. A driver who updates their vehicle information expects that change to apply immediately. A rider who changes their home address expects the app to remember it on the next open. These expectations push toward shorter cache TTLs, which increases database load.

Real-Time Challenges

Uber’s system processes millions of requests per day, but the interesting challenges are not about throughput. They are about latency and consistency under load.

The hardest scenario is peak demand. New Year’s Eve in a major city. A concert letting out. A sudden rainstorm. The app sees a spike in requests, drivers become scarce, and the system has to make decisions fast.

In these moments, cascading failures become likely. High load on one service causes timeouts. Timeouts cause retries. Retries multiply the load. The dispatch service has to handle this gracefully, falling back to cached data or degraded modes rather than failing completely.

Uber’s engineers have written about implementing circuit breakers at the service boundary. When a downstream service is slow, the caller stops waiting and applies a default behavior. For dispatch, that might mean showing the rider an estimated wait time based on last-known availability.

Another challenge is global consistency with local latency. Uber wants the same pricing rules everywhere, but riders in São Paulo should not wait longer for a price quote than riders in San Francisco. This pushes toward caching and regional data centers, which introduces its own consistency headaches.

Data Architecture

Uber’s data layer reflects the microservices philosophy: each service owns its data. There is no shared database, no cross-service queries, no joins across domains.

In practice, this means schema-per-service. The user service uses PostgreSQL for relational data. The payment service uses Cassandra for write-heavy audit logs. The dispatch service uses a mix depending on the specific data needs.

The databases are not directly accessible across service boundaries. If dispatch needs user information, it calls the user service API. This adds latency, but it also means a database issue in payments does not cascade into dispatch.

graph LR
    subgraph "Service A"
        ServiceA[Service]
        DBA[(DB A)]
    end

    subgraph "Service B"
        ServiceB[Service]
        DBB[(DB B)]
    end

    ServiceA -->|API Call| ServiceB
        ServiceB -->|Read/Write| DBB
        ServiceA -->|Read/Write| DBA

Caching layers sit in front of the databases. Most services maintain a Redis cache for frequently accessed data. The cache-aside pattern is common: check cache first, fall back to database on miss, populate cache for subsequent requests.

Cache invalidation is where things get messy. When a driver’s vehicle information changes, the user service invalidates its cache. But the dispatch service might have cached that same driver data. The cache lives outside the service boundary, so invalidation signals have to propagate somehow.

Uber addressed this through a pub/sub system. When data changes, the owning service publishes an event. Interested services subscribe and invalidate their local caches. This adds complexity but keeps data reasonably fresh without constant database polling.

RingPOP: Distributed Coordination

One of Uber’s more interesting internal tools is RingPOP. It provides distributed, fault-tolerant state management using a consistent hashing ring.

The idea is straightforward: nodes in a cluster organize into a ring. Each node owns a portion of the key space based on its position on the ring. When you need to find a key, you hash it and walk the ring to the appropriate node.

RingPOP adds membership and failure detection on top of this. Nodes periodically exchange heartbeat messages. If a node misses too many heartbeats, the ring reorganizes and its portion of the key space gets reassigned.

Uber uses RingPOP for coordination tasks that require agreement across nodes. The classic example is leader election for partitioned resources. If a dispatch instance goes down, another instance needs to pick up its active trips. RingPOP helps coordinate this handoff.

The tool is not without issues. Consistent hashing rings are sensitive to network partitions. If enough nodes are unreachable, the ring cannot reach consensus and operations stall. Uber’s engineers have had to tune timeouts carefully to balance responsiveness against false failure detection.

Hades: Incident Management

Hades is Uber’s internal incident management platform. When something goes wrong, Hades coordinates the response.

The system automates some of the boilerplate around incidents. It pages on-call engineers based on severity. It creates communication channels, assigns roles, and tracks action items. It generates post-mortems by correlating logs and metrics around the incident timeline.

What makes Hades interesting architecturally is its integration with the rest of the platform. It does not just sit on top as an independent tool. It has hooks into service health dashboards, deployment pipelines, and configuration management.

When an incident triggers, Hades can automatically roll back a suspect deployment or throttle traffic to a failing service. This tight integration means faster response, but it also means Hades has to understand the health signals coming from many different systems.

The downside is coupling between Hades and the platform services it monitors. If a service changes how it reports health, Hades needs updating too. This is a common problem with internal tooling: the thing that helps during incidents can itself become an incident.

Mobility Platform Architecture

Uber expanded beyond ride-sharing into外卖, freight, and other mobility categories. Each expansion raised the question of how much to share with existing services.

The mobility platform architecture attempts to reuse core services where possible. Dispatch logic varies by product type, but the underlying matching algorithms share common roots. Pricing follows similar structures across categories. User and driver accounts are shared because the same people use multiple Uber products.

However, product-specific logic gets its own services. The freight dispatch system has different constraints than ride-sharing. Restaurant delivery has its own supply model. Trying to force everything into the same services would create the same coupling problems Uber had with the monolith.

The architectural pattern here is extension rather than modification. Core services remain stable. Product-specific logic builds on top or sits alongside. This keeps the base platform reusable while allowing product teams to move fast on their own requirements.

Interview Q&A

Q: Why did Uber move from a monolith to microservices?

A: The monolith created deployment coupling. Different teams needed different release cycles, but a single codebase meant all changes shipped together. A pricing bug could delay dispatch. Compilation times grew with codebase size. Scaling one component required scaling everything, even components not under load.

Q: How does RingPOP provide fault tolerance?

A: RingPOP uses consistent hashing to partition keys across nodes. Nodes exchange periodic heartbeats to detect failures. If a node misses too many heartbeats, the ring reorganizes and reassigns its key space. For leader election, when a dispatch instance fails, RingPOP helps coordinate the handoff so another instance picks up its active trips.

Q: What is the difference between service orchestration and choreography at Uber?

A: Uber uses choreography-based coordination. Services react to events published by other services rather than being directed by an orchestrator. When a trip completes, the payment service publishes an event. The dispatch service subscribes and updates driver availability. This keeps services loosely coupled but makes debugging harder since there is no central workflow view.

Q: How does Hades integrate with the rest of the platform?

A: Hades has hooks into service health dashboards, deployment pipelines, and configuration management. When an incident triggers, Hades can automatically roll back a suspect deployment or throttle traffic to a failing service. This tight integration enables faster response but creates coupling between Hades and platform services.

---

Scenario Drills

Scenario 1: Dispatch Service Overload During Peak Demand

Situation: New Year’s Eve in a major city. A concert letting out. Request volume spikes 10x while driver supply decreases.

Analysis:

• Dispatch receives burst requests faster than it can process
• Calls to pricing, ETAs, and driver availability services timeout
• Retries from timeouts multiply load on already stressed services
• Cascading failure becomes likely

Solution: Implement circuit breakers at service boundaries. When downstream services are slow, dispatch applies default behavior (estimated wait time from last-known availability) rather than waiting for fresh data. Queue requests for batch processing to smooth spikes.

Scenario 2: Driver Updates Vehicle Information

Situation: A driver updates their vehicle information while trips are in progress.

Analysis:

• Dispatch has cached the driver’s old vehicle data
• User service invalidates its cache
• But dispatch may have stale data until cache expires
• Trip could match rider with outdated vehicle info

Solution: Uber uses pub/sub for cache invalidation. When driver data changes, the user service publishes an event. Interested services like dispatch subscribe and invalidate their local caches. This propagates invalidation without direct cross-service calls.

Scenario 3: Database Failure in Payment Service

Situation: The payment service database becomes unavailable mid-transaction.

Analysis:

• Payment cannot commit or rollback
• Rider app shows payment pending but trip status unclear
• Financial audit trail is incomplete
• Disputes could arise from ambiguous state

Solution: Payment service uses synchronous, reliable communication and Cassandra for write-heavy audit logs. If a charge succeeds, the record reflects it immediately. For partial failures, saga pattern coordinates compensation across services.

---

Failure Flow Diagrams

Dispatch Request Flow

graph TD
    A[Rider Requests Ride] --> B{Dispatch Available?}
    B -->|No| C[Return Service Unavailable]
    B -->|Yes| D[Calculate ETA]
    D --> E{Pricing Available?}
    E -->|No| F[Use Cached Pricing]
    E -->|Yes| G[Fetch Surge Multiplier]
    F --> H[Find Nearby Drivers]
    G --> H
    H --> I{Drivers Available?}
    I -->|No| J[Queue Request]
    I -->|Yes| K[Match Driver]
    K --> L[Send Ride Request]
    L --> M{Driver Accepts?}
    M -->|Timeout| J
    M -->|Accept| N[Trip Started]
    J --> D

Circuit Breaker Flow

graph TD
    A[Service Call] --> B{Circuit State?}
    B -->|Closed| C[Execute Call]
    C --> D{Call Succeeds?}
    D -->|Yes| E[Reset Failure Count]
    D -->|No| F[Increment Failure Count]
    F --> G{Failure Threshold?}
    G -->|No| E
    G -->|Yes| H[Open Circuit]
    E --> I[Return Response]

    B -->|Open| J{Timeout Elapsed?}
    J -->|No| K[Reject Immediately]
    J -->|Yes| L[Half-Open]
    L --> M[Allow Test Call]
    M --> N{Call Succeeds?}
    N -->|Yes| O[Close Circuit]
    N -->|No| P[Reset Timeout, Stay Open]
    K --> I

Cache Invalidation Flow

graph LR
    A[Data Change Event] --> B{Validate Cache?}
    B --> C[Publish to Pub/Sub]
    C --> D[Subscriber Services]
    D --> E{Service Has Cached Data?}
    E -->|Yes| F[Delete Cache Entry]
    E -->|No| G[No Action]
    F --> H[Next Request Triggers DB Read]
    G --> H
    H --> I[Populate Cache]

---

Capacity Estimation

Request Volume

Daily trips: 15 million (average)
Peak hour factor: 3x average
Peak trips/hour: 15M / 16 hours × 3 = 2.8 million
Peak trips/second: 2.8M / 3600 ≈ 780 trips/second

Dispatch latency budget: < 500ms
Timeout threshold: 1 second

Driver Matching Computation

Average drivers to evaluate per request: 50
Nearby radius: 3 miles
Active drivers per region: 10,000

Batch optimization (batching nearby requests):
- Batch size: 10 requests
- Computation: 10 × 50 = 500 driver evaluations per batch
- Time: ~100ms for optimal assignment

Storage Requirements

Trip records per day: 15M
Average trip size: 2KB (metadata, route, pricing)
Daily storage: 15M × 2KB = 30 GB
5-year retention: 30GB × 365 × 5 = 55 TB
With 3x replication: ~165 TB

---

Key Lessons

Uber’s architectural evolution offers several takeaways.

First, microservices solve an organizational problem before a technical one. The services at Uber map to teams and business capabilities. The architecture enables independent deployment and development. If your team is small and moves fast, a monolith might serve you better.

Second, distributed systems add complexity that has to be managed. RingPOP, Hades, caching layers, circuit breakers: the supporting infrastructure is substantial. Each piece solves a real problem but also introduces its own failure modes. The net complexity might be higher than a monolith, even if the individual services are simpler.

Third, data ownership boundaries matter. Uber’s schema-per-service approach works because each service’s data needs are well-defined and stable. If your services need to share data heavily, the boundaries might be wrong. Cross-service joins through APIs are painful enough that boundary mistakes are expensive to fix.

Fourth, real-time requirements drive architectural decisions in ways that batch processing does not. The latency budget for dispatch is tight. This constrains how services can call each other and how much state they can maintain locally. Batch-oriented systems can be more forgiving.

Fifth, observability is not optional. With dozens of services in play, understanding what is happening when something breaks requires good logging, tracing, and metrics. Uber’s investment in Hades and related tooling reflects this. If you cannot see inside your system, you cannot operate it.

Related Posts

If this post interests you, several others on GeekWorkBench explore related topics:

• Designing a Chat System covers real-time messaging patterns that appear in Uber’s rider-driver communication.
• The Saga Pattern addresses distributed transaction management, relevant to how Uber coordinates multi-step operations.
• Service Orchestration explores patterns for coordinating microservices, contrasting with Uber’s choreography-based approach.
• Event-Driven Architecture digs deeper into the async communication patterns that power Uber’s loosely coupled services.

Each of these topics connects to the broader challenge of building distributed systems at scale. Uber’s approach is one data point among many. The right architecture depends on your specific constraints, team structure, and business requirements.

---

Quick Recap

• Microservices solve organizational problems before technical ones; boundaries map to team ownership.
• Schema-per-service prevents hidden coupling but requires careful API design.
• RingPOP provides distributed coordination via consistent hashing with membership detection.
• Circuit breakers prevent cascading failures when downstream services are slow.
• Hades integrates incident management with deployment pipelines for automated response.
• Cache invalidation via pub/sub keeps distributed caches reasonably fresh.
• Real-time requirements tighten latency budgets and constrain service call patterns.