How Uber Works — System Design Deep Dive

Opening: Three Seconds That Move a Continent

You tap Request. Your phone sends a payload a few hundred bytes wide: who you are, where you are (with uncertainty), which product you want (UberX, Comfort, XL…), and a fingerprint of your session. Within roughly one to three seconds—often under two on a healthy network—you see a driver’s name, vehicle, and an ETA. Behind that mundane UX is one of the largest real-time control systems on Earth: geospatial indexing over millions of moving nodes, dispatch optimization under hard latency SLOs, routing and traffic fusion, dynamic pricing, fraud and risk, payments and settlement, and regional failover when dependencies misbehave.

This article is a case study in how Uber’s engineering organization turned that impossible problem into a domain-oriented microservice fabric with well-known open-source footprints (H3, Jaeger, contributions around Kafka, Pinot, Flink, MySQL scaling patterns, and more). Numbers below are order-of-magnitude anchors drawn from public talks, engineering blogs, and industry reporting—Uber’s internal figures move every quarter, but the shapes (what breaks first, what must never break) are stable.

The scale that constrains every design choice

1. The Scale of Uber — Numbers That Rewrite Intuition

Uber is not “an app.” It is a marketplace control plane layered on top of maps, payments, trust & safety, and local regulation. The product surface is simple; the failure surface is enormous.

1.1 Uber by the numbers (publicly anchored)

1.2 End-to-end latency budget (why 3 seconds is a hard constraint)

The rider only experiences one timer, but the server stitches dozens of internal steps. A back-of-the-envelope for an on-demand match in a dense city might look like:

Nothing here is “free.” If routing p99 slips by 200 ms, you consume the entire budget for reoffer rounds—so dispatch systems pre-trim candidates aggressively and cache segment speeds.

1.3 Infrastructure footprint: hybrid reality

Uber runs a hybrid footprint: owned data centers plus public cloud capacity, regionally distributed, with active-active ambitions for the most critical domains. The exact split is operationally sensitive, but the pattern is universal:

flowchart TB
  subgraph Mobile["Mobile clients"]
    R[Rider app]
    D[Driver app]
  end
  subgraph Edge["Edge & API tier"]
    DNS[DNS / Anycast]
    GW[API Gateway\nauth, rate limits]
  end
  subgraph Region["Regional control plane"]
    DIS[dispatch-core]
    RT[routing + traffic]
    PR[pricing]
    PY[payments / risk]
    GS[geospatial index svc]
  end
  subgraph Data["Data planes"]
    K[Kafka clusters]
    DB[(OLTP: MySQL / Schemaless)]
    CA[(Cassandra wide-column)]
    RD[(Redis cache + pubsub)]
    OLAP[(Pinot / OLAP)]
  end
  R --> DNS --> GW
  D --> DNS --> GW
  GW --> DIS
  GW --> RT
  GW --> PR
  DIS --> GS
  DIS --> RT
  DIS --> K
  RT --> K
  PR --> K
  PY --> DB
  K --> OLAP

2. Uber's Architecture Evolution — Monolith to DOMA

Uber’s trajectory mirrors every hypergrowth company—except the spatial and economic coupling is tighter, so mistakes become visible on a heatmap within minutes.

flowchart LR
  M[Monolith\nPython + Postgres] --> S[SOA\nextract hot paths]
  S --> D[DOMA\nDomains + Gateways\n+ extension layers]
  style M fill:#f8d7da
  style S fill:#fff3cd
  style D fill:#d4edda

2.1 DOMA in one paragraph

DOMA pushes teams to define domain boundaries that match business capabilities (matching, pricing, identity, payments), expose versioned APIs via gateways, and isolate experimental extensions so product lines can reuse platforms without forking them. Practically, that means fewer blocking calls across domains, more event-driven integration, and SLO-tiered dependencies (Tier-0 payment paths differ from Tier-2 recommendation features).

3. High-Level Architecture — The Microservice Landscape

No public diagram lists every production service—nor should it. What is stable is the capability map: a few Tier-0 paths (safety, payments, trip state) and many Tier-1/2 enrichments (recommendations, incentives UI, support tooling).

3.1 Representative service map (20+ logical services)

3.2 RPC evolution: TChannel → gRPC (+ Envoy)

Uber historically invested in TChannel / Thrift-style RPC stacks for internal performance. The industry converged on gRPC + HTTP/2 and Envoy-class sidecars for retry budgets, outlier detection, and per-route timeouts. The architectural invariant: synchronous RPC must be bounded—every hop needs deadlines propagated on the wire.

flowchart TB
  subgraph Clients["Clients"]
    RA[Rider]
    DA[Driver]
  end
  subgraph Edge["Edge"]
    APIGW[API Gateway]
  end
  subgraph Core["Core domains"]
    DEM[demand-svc]
    SUP[supply-svc]
    GEO[geo-index-svc]
    DIS[dispatch-svc]
    RTE[routing-svc]
    SUR[surge-svc]
    FARE[fare-svc]
    PAY[payments-svc]
    RT[realtime-gw]
  end
  subgraph Async["Async bus"]
    K[Kafka]
  end
  RA --> APIGW
  DA --> APIGW
  APIGW --> DEM
  APIGW --> SUP
  DIS --> GEO
  DIS --> RTE
  DIS --> SUR
  DEM --> DIS
  SUP --> GEO
  FARE --> SUR
  FARE --> RTE
  PAY --> K
  DIS --> K
  RT --> RA
  RT --> DA

4. The Ride Lifecycle — Step by Step

4.1 Request creation

1. Client validation — product available in market, payment method present, location permissions sane.
2. Eligibility — business rules, age, region locks.
3. Fraud / risk pre-checks — velocity on device, account history, chargeback risk.
4. Geohash/H3 bucketing — attach request to spatial partition for dispatch.
5. Persist intent — create trip request record with idempotency key (network retries are guaranteed).

4.2 Driver matching (dispatch)

Dispatch pulls candidate drivers from the spatial index, ranks by ETA and fairness, sends offers, handles accept/timeout, and may reoffer with backoff. Pooling adds combinatorial constraints.

4.3 Navigation and routing

Once matched, both apps need consistent ETAs and routes. The server computes authoritative ETAs for pricing and SLA; clients may use on-device navigation SDKs for turn-by-turn while periodically reconciling.

4.4 Trip tracking

High-frequency GPS is sampled, map-matched, and streamed through the realtime gateway. Riders see live location; dispatch sees updated ETAs.

4.5 Completion, fare, payment

On dropoff, the fare engine closes the trip: distance/time reconciliation, tolls, surge application, promotions, then capture against the payment instrument.

4.6 Ratings and feedback

Post-trip events update two-sided reputation systems and feed trust models—often asynchronously to keep completion latency tight.

sequenceDiagram
  participant R as Rider app
  participant G as API Gateway
  participant D as demand-svc
  participant X as dispatch-svc
  participant S as supply-svc
  participant Q as geo-index
  participant T as routing-svc
  participant P as payments-svc
  participant K as Kafka
  R->>G: POST /requests (idempotent)
  G->>D: createRequest()
  D->>K: TripRequested
  D->>X: scheduleMatching(tripId)
  X->>Q: queryCandidates(H3, filters)
  Q-->>X: driver ids + coarse locs
  X->>T: batchETA(drivers, pickup)
  T-->>X: eta matrix
  X->>S: sendOffer(driverA)
  S-->>R: push + WS update
  R-->>G: driver accepted (client poll/WS)
  G-->>R: trip object
  Note over R,P: During trip: location ticks, reroutes, surge updates
  R->>G: completeTrip()
  G->>P: captureFare()
  P->>K: PaymentCaptured

stateDiagram-v2
  [*] --> REQUESTED
  REQUESTED --> MATCHING: persist + enqueue
  MATCHING --> ACCEPTED: driver accepts
  MATCHING --> CANCELLED: rider/driver/system
  ACCEPTED --> EN_ROUTE: driver started
  EN_ROUTE --> ARRIVED: at pickup
  ARRIVED --> ON_TRIP: rider on board
  ON_TRIP --> COMPLETED: dropoff
  COMPLETED --> SETTLED: fare finalized
  SETTLED --> [*]
  ON_TRIP --> CANCELLED: mid-trip cancel policy

5. Geospatial Indexing — The Heart of Uber

Naive approaches—“SELECT * FROM drivers WHERE distance < 2km”—die immediately:

5.1 Google S2 geometry (deep dive)

S2 partitions the sphere into hierarchical quadrilateral cells (a space-filling curve aids locality). Each cell has a 64-bit ID, levels 0–30, and supports fast containment tests and region covering.

Hilbert curve ordering means geographically close points often share nearby cell IDs, helping memory locality in indexes (though not perfectly—poles and edges need care).

flowchart TB
  E[Earth sphere] --> L0[Coarse cells\nlow level]
  L0 --> L1[Subdivide\nhigher level]
  L1 --> L2[Finer cells\nmany children]
  L2 --> Q[Point query:\nlocate leaf cell]

5.2 Uber H3 (hexagonal hierarchical index)

H3 is Uber’s open-source hexagonal grid. Key properties:

k-ring expansion grows search radius in discrete steps—critical for dispatch’s “widen search if no takers” logic.

5.3 H3 vs S2 vs Geohash vs R-tree vs Quadtree

5.4 Java: grid-based spatial index (compilable sketch)

This is a pedagogical implementation—production adds sharding, WAL, epoch GC, and lock-free structures. It compiles standalone and shows the cell → bucket → candidate pattern.

// SpatialGridIndex.java — javac SpatialGridIndex.java && java SpatialGridIndex
import java.util.*;
import java.util.concurrent.ConcurrentHashMap;
 
/** Fixed grid in degrees (demo only — production uses H3/S2 IDs as keys). */
public final class SpatialGridIndex {
 
    private final double cellDegreesLat;
    private final double cellDegreesLng;
    private final Map<Long, Set<String>> cellToDrivers = new ConcurrentHashMap<>();
 
    public SpatialGridIndex(double cellDegreesLat, double cellDegreesLng) {
        this.cellDegreesLat = cellDegreesLat;
        this.cellDegreesLng = cellDegreesLng;
    }
 
    public static long cellId(double lat, double lng, double dLat, double dLng) {
        int gy = (int) Math.floor(lat / dLat);
        int gx = (int) Math.floor(lng / dLng);
        return ((long) gy << 32) | (gx & 0xffffffffL);
    }
 
    public void upsertDriver(String driverId, double lat, double lng) {
        long id = cellId(lat, lng, cellDegreesLat, cellDegreesLng);
        cellToDrivers.computeIfAbsent(id, k -> ConcurrentHashMap.newKeySet()).add(driverId);
    }
 
    public void removeDriver(String driverId, double lat, double lng) {
        long id = cellId(lat, lng, cellDegreesLat, cellDegreesLng);
        Set<String> bucket = cellToDrivers.get(id);
        if (bucket != null) {
            bucket.remove(driverId);
            if (bucket.isEmpty()) {
                cellToDrivers.remove(id, bucket);
            }
        }
    }
 
    /** Naive neighbor search: origin cell + 8 adjacent grid steps (3×3). */
    public Set<String> nearby(double lat, double lng) {
        int gy = (int) Math.floor(lat / cellDegreesLat);
        int gx = (int) Math.floor(lng / cellDegreesLng);
        Set<String> out = new HashSet<>();
        for (int dy = -1; dy <= 1; dy++) {
            for (int dx = -1; dx <= 1; dx++) {
                long id = ((long) (gy + dy) << 32) | (((long) (gx + dx)) & 0xffffffffL);
                Set<String> b = cellToDrivers.get(id);
                if (b != null) {
                    out.addAll(b);
                }
            }
        }
        return out;
    }
 
    public static void main(String[] args) {
        SpatialGridIndex idx = new SpatialGridIndex(0.01, 0.01);
        idx.upsertDriver("d1", 37.77, -122.42);
        idx.upsertDriver("d2", 37.771, -122.421);
        System.out.println(idx.nearby(37.77, -122.42));
    }
}

5.5 Millions of location updates per second

flowchart LR
  GPS["lat/lng + accuracy"] --> CELL["cellId = H3 index at resolution"]
  CELL --> BKT[fetch bucket drivers]
  BKT --> FILT[hard filters\nvehicle, product, ban-list]
  FILT --> RANK[ETA + fairness score]
  RANK --> OFFR[send offers]

6. The Dispatch System — Driver Matching

Dispatch is a continuous optimization problem disguised as an API.

6.1 Supply positioning and demand prediction

6.2 Candidate generation

1. H3 k-ring around pickup at resolution tuned to density.
2. Filter: product match, document validity, cooldown from prior declines.
3. Cap to top-N before expensive ETA matrix calls.

6.3 ETA-based ranking

ETA dominates rider UX; it is the primary score before tie-breakers (fairness, idle time, quality).

6.4 Batch vs greedy

6.5 Fairness and anti-gaming

6.6 Scheduled vs on-demand

Scheduled rides shift time constraints into optimization windows—dispatch pre-commits capacity closer to pickup time while sending reminder pushes.

6.7 Pool / shared rides

Pooling introduces pickup order and delay constraints for each rider. The optimizer minimizes total vehicle-minutes subject to SLA caps.

flowchart TB
  A[New trip request] --> B[spatial candidates]
  B --> C[batch ETA]
  C --> D[score + fairness tie-break]
  D --> E[send top-K offers]
  E --> F{accept in T seconds?}
  F -- yes --> G[bind trip]
  F -- no --> H[widen k-ring / adjust surge]
  H --> B

flowchart LR
  V[Vehicle] --> P1[Pickup A]
  P1 --> P2[Pickup B]
  P2 --> D1[Dropoff A]
  D1 --> D2[Dropoff B]

6.8 Batch ETA as a linear algebra mindset

When N drivers meet M trip offers (pooling, chained pickups), you conceptually build a cost matrix C[i][j] (ETA or earnings-adjusted ETA). Exact assignment is assignment problem / min-cost matching territory—Hungarian algorithm in O(n³) for dense matrices. Production systems rarely solve full global optima on every tick; they window the problem (top-K drivers × active trips) and warm-start from the previous second’s solution.

6.9 Java: greedy ETA matcher (compilable)

// GreedyDispatchMatcher.java — compile with SpatialGridIndex in same dir or adjust packages
import java.util.*;
 
public final class GreedyDispatchMatcher {
 
    public record Driver(String id, double lat, double lng, double etaMinutes) {}
 
    public Optional<Driver> pickBest(Collection<Driver> candidates) {
        return candidates.stream().min(Comparator.comparingDouble(Driver::etaMinutes));
    }
 
    public static void main(String[] args) {
        var m = new GreedyDispatchMatcher();
        List<Driver> c = List.of(
            new Driver("a", 0, 0, 4.2),
            new Driver("b", 0, 0, 3.1),
            new Driver("c", 0, 0, 5.0)
        );
        System.out.println(m.pickBest(c));
    }
}

7. ETA Calculation — Deep Dive

7.1 Road graph

Digital maps become a weighted directed graph: nodes are topology points; edges are road segments with distance, speed priors, turn penalties, and access rules.

7.2 Algorithms

flowchart TB
  G[Road graph\nCH / CRP / custom] --> Q[Shortest path query]
  T[Live segment speeds] --> F[Fuse weights]
  Q --> F
  F --> B[Base ETA]
  M[ML calibration] --> E[Displayed ETA]
  B --> M

7.3 Map matching

GPS error clouds snap to polylines using hidden Markov or particle methods. Bad snapping skews distance and breaks surge borders.

7.4 Real-time traffic

flowchart LR
  P[Probes stream] --> A[map-match to segments]
  A --> S[speed estimator]
  S --> U[update edge weights]
  U --> R[routing queries see new costs]

7.5 ML calibration and fallbacks

When routing degrades (map incident, partial outage), fall back to haversine bounds, historical priors, and wider confidence intervals on the UI. Never silently promise impossible precision.

8. Surge Pricing (Dynamic Pricing)

8.1 Economics

Surge is a price signal to balance marginal supply and demand. In control-theory terms, it’s a feedback loop with human actors—latency and transparency shape stability.

8.2 Computing multipliers

flowchart LR
  D[Demand intensity] --> I[Imbalance metric]
  S[Supply availability] --> I
  I --> M[Multiplier function]
  M --> R[Rider price]
  M --> V[Driver incentives]

8.3 Geofencing and temporal patterns

Airports, stadiums, and weather spikes produce sharp local gradients. Systems pre-materialize geofence metadata to avoid recomputing polygons on the hot path.

8.4 Anti-gaming and regulation

8.5 Upfront vs time-and-distance

Upfront pricing fixes rider exposure but shifts risk to prediction error models—ties directly back to Section 7.

flowchart TB
  TE[Telemetry] --> Z[Zone imbalance]
  Z --> POL[Policy engine\njurisdiction rules]
  POL --> FE[Fare engine]
  FE --> UI[Client display]

9. Payment System — Deep Dive

9.1 Fare calculation

9.2 Methods by region

9.3 Auth hold and capture

Authorization reserves funds; capture happens on completion (or cancellation rules). Idempotent captures prevent duplicate charges on retries.

9.4 Fraud detection

sequenceDiagram
  participant C as Client
  participant P as payments-svc
  participant R as risk-svc
  participant PS as Processor
  C->>P: authorize(hold)
  P->>R: score()
  R-->>P: allow / challenge
  P->>PS: AUTH
  PS-->>P: auth code
  Note over C,PS: Trip runs...
  C->>P: capture(tripId)
  P->>PS: CAPTURE
  PS-->>P: receipt

flowchart TB
  E[Event: add card / trip pay] --> R1[rules engine]
  R1 --> R2[graph features]
  R2 --> R3[ML model ensemble]
  R3 --> DEC{Decision}
  DEC -->|allow| OK[continue]
  DEC -->|challenge| CH[3DS / OTP]
  DEC -->|block| BL[hard decline + audit]

9.5 Payouts, tips, promos, credits

Driver payouts batch through ledger systems with tax forms and instant pay options where supported. Tips flow as separate ledger lines. Promo codes require per-user caps and accounting segregation.

10. Real-Time Communication Infrastructure

10.1 WebSockets and alternatives

flowchart TB
  D[Driver app] -->|GPS tick| GW[realtime-gw]
  GW -->|normalize| K[Kafka trip.topic]
  GW -->|fan-out| R[Rider subscriptions]
  subgraph Pool["Connection pool"]
    WS1[WS session]
    WS2[WS session]
  end
  R --> Pool

10.2 Push notifications

APNs/FCM carry collapse keys so the latest ETA replaces stale notifications.

sequenceDiagram
  participant S as trip-svc
  participant N as notify-svc
  participant F as FCM/APNs
  participant U as User device
  S->>N: TripStateChanged
  N->>F: send(token, payload)
  F-->>U: display / data push

10.3 Delivery guarantees and mobile unreliability

Assume at-least-once. Clients dedupe by (tripId, seq) or version fields. On reconnect, snapshot current trip state from an API—not from message backlog alone.

11. Data Infrastructure

11.1 Kafka at Uber-scale

Public materials reference trillions of messages and thousands of topics. Operational necessities:

flowchart LR
  SVC[services] --> K[Kafka]
  K --> F[Flink jobs]
  K --> P[Pinot ingest]
  K --> H[Hudi lake]
  F --> FE[features / alerts]

11.2 Storage systems

11.3 Stream processing and ML platform

Apache Flink powers real-time aggregation; Michelangelo (Uber ML platform, public talks) covers training, feature stores, and serving—connecting Kafka features to online models for ETA, fraud, and demand forecasting.

flowchart TB
  LOG[Event logs] --> FT[Feature pipelines]
  FT --> TR[Trainer]
  TR --> REG[Model registry]
  REG --> SV[Online serving]
  RT[Realtime events] --> SV
  SV --> PR[predictions back to services]

11.4 Trust, safety, and privacy-aware telemetry

Uber-scale telemetry is both a product advantage (ETA, fraud) and a civil liberties surface (movement traces). Architecturally, the same patterns appear: purpose limitation, aggregation, retention tiers, and access auditing.

flowchart TB
  P[Phone GPS] --> E[Edge gateway]
  E --> H[H3 coarse cell\nfor analytics]
  E --> D[dispatch hot path\nfiner resolution]
  H --> K[Kafka aggregate topics]
  D --> DIS[matching only]

12. Uber's Technology Stack

12.1 Open-source footprint (sample)

12.2 Schemaless in one paragraph (sharded MySQL done seriously)

Uber’s Schemaless layer (public engineering posts) is not “NoSQL in MySQL”—it is an orchestrated sharding approach with triggers, indexes, and workflows to scale wide rows and high-cardinality keys without turning every engineer into a DBA. Think application-level partitioning with consistent hashing, resharding playbooks, and online schema evolution guarded by automation.

12.3 Framework and platform matrix (illustrative)

// BAD: O(n) — scans every online row per request
// SELECT driver_id FROM drivers WHERE ST_Distance(loc, ?) < 2000 AND online=1;
import java.util.ArrayList;
import java.util.List;
 
public final class NaiveSpatialQuery {
    public List<String> allWithinKm(List<DriverRow> table, double lat, double lng) {
        List<String> out = new ArrayList<>();
        for (DriverRow r : table) {
            if (haversineKm(lat, lng, r.lat, r.lng) < 2.0 && r.online) {
                out.add(r.id);
            }
        }
        return out;
    }
    private static double haversineKm(double lat1, double lon1, double lat2, double lon2) {
        final double earthKm = 6371.0;
        double dLat = Math.toRadians(lat2 - lat1);
        double dLon = Math.toRadians(lon2 - lon1);
        double a = Math.sin(dLat / 2) * Math.sin(dLat / 2)
                + Math.cos(Math.toRadians(lat1)) * Math.cos(Math.toRadians(lat2))
                * Math.sin(dLon / 2) * Math.sin(dLon / 2);
        double c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a));
        return earthKm * c;
    }
    private record DriverRow(String id, double lat, double lng, boolean online) {}
}

13. Reliability and Fault Tolerance

13.1 Multi-region

Active-active patterns require conflict resolution for trip state—leader regions per trip or CRDT-like constraints are common patterns in industry.

13.2 Circuit breakers and bulkheads

stateDiagram-v2
  [*] --> CLOSED
  CLOSED --> OPEN: error rate > threshold
  OPEN --> HALF_OPEN: after sleep window
  HALF_OPEN --> CLOSED: probe success
  HALF_OPEN --> OPEN: probe failure

13.3 Graceful degradation hierarchy

flowchart TB
  R1[Region A] -->|failing SLO| DNS[Traffic shift]
  DNS --> R2[Region B]
  R2 --> DB[(replicated data)]

13.4 Chaos and SRE

GameDays inject latency, packet loss, and dependency failure to validate fallbacks. SRE practices align error budgets to feature velocity—matching Tier-0 services stricter budgets.

13.5 SLO starter pack and incident command

flowchart LR
  A[Alert fires] --> B[Incident commander]
  B --> C[Mitigate: degrade / failover]
  C --> D[Status page + comms]
  D --> E[Postmortem]
  E --> F[Action items: SLO + code + runbooks]

13.6 Degradation ladder (explicit ordering)

flowchart TB
  OLAP[OLAP / BI queries] --> FEAT[Recommendations]
  FEAT --> SUR[Surge granularity]
  SUR --> RT[Realtime map polish]
  RT --> DIS[dispatch optimality]
  DIS --> PAY[Tier-0: payments + trip truth]
  style PAY fill:#d4edda
  style OLAP fill:#f8d7da

14. Lessons Learned and Key Takeaways

14.1 Patterns to steal

14.2 Common mistakes in ride-sharing design

14.3 Interview tips (Uber-style system design)

1. Start with SLO: p95 match latency, consistency model for trip state.
2. Draw spatial index before algorithms.
3. Separate pricing, dispatch, and payments boundaries.
4. Discuss failure: retries, circuit breakers, regional failover.
5. Mention observability: metrics, logs, traces for dispatch loops.

14.4 Further reading (official / authoritative)

Additional entry points:

• Uber Engineering hub: https://eng.uber.com/ — filter by Infra, Data, AI, and Mobile tags
• Uber Open Source directory: https://opensource.uber.com/ — H3, Jaeger, and historical platform tools

14.5 Capacity planning thought experiment

Suppose a metro peaks at ~8k concurrent online drivers and ~15k open trip intents during a concert egress (illustrative). A 1 Hz location heartbeat (after coalescing) implies ~8k writes/s to the spatial index partition for that metro alone, before fan-out to dispatch consumers. If your design stores one giant row per city, you will serialise updates and die. If you partition by H3 cell at resolution 8–9, you spread writes across thousands of buckets—exactly the point of hierarchical spatial indexes.

14.6 Glossary (quick scan)

14.7 Whiteboard drills (with expected talking points)

14.8 Observability checklist (production-grade)

14.9 Regulatory and marketplace reality (non-optional context)

Architects ignore policy tables at their peril. Cities differ on cash, vehicle class caps, dynamic pricing disclosure, and data localization. The implementation pattern is not scattered if (city == "X") branches in every service—it is versioned configuration loaded into policy engines with audit trails, evaluated close to pricing and dispatch decisions.

flowchart TB
  T[Telemetry] --> POL[Policy engine\njurisdiction config]
  POL --> PR[pricing outputs]
  POL --> DS[dispatch constraints]
  POL --> AUD[audit log]

Epilogue: Why this problem stays fascinating

Uber’s stack is a living lesson that geometry + economics + mobile unreliability forces distributed systems to grow up fast. Build the indexes first, keep money paths boringly correct, and treat ETA as both UX and financial derivative. Do that, and you’ve earned the right to optimize the elegant details—batch matching, pooled routes, and the endless craft of fair marketplaces.