Uber: Domain-Oriented Microservice Architecture (DOMA) & H3 Geospatial

Uber initially started with a monolithic Python and Node.js backend. As the company expanded to hundreds of cities worldwide, it transitioned aggressively to microservices. By 2018, Uber's production environment had exploded into over 4,000 independent microservices running on tens of thousands of container instances.

This hyper-granularity triggered a severe architectural crisis known internally as the "Microservice Death Star":

• Dependency Hell & Circular Cascades: A single ride request frequently traversed over 50 downstream microservices in complex, cyclic dependency webs. A minor latency spike in a non-critical coupon service could lock database connections upstream, taking down driver dispatch globally.
• Extreme Cognitive Load: Onboarding new software engineers required months of navigating ambiguous service ownership. Nobody understood the holistic call graph.
• Untestable Integration Surfaces: Integration testing became virtually impossible; staging environments could not mirror the volatile interdependencies of 4,000 independently deploying services.

To restore architectural order without returning to a monolithic codebase, Uber engineered Domain-Oriented Microservice Architecture (DOMA). DOMA reorganizes microservices around clean domain boundaries, single gateways, and strict layering:

1. Bounded Domains:

Instead of treating 4,000 services as a flat mesh, DOMA groups 10 to 100 related microservices into a cohesive Domain (e.g., Rides, Eats, Maps, Payments, Fulfillment).

2. Domain Gateways:

Each Domain exposes its capabilities exclusively through a single Domain Gateway.

• The 50 underlying microservices within the Rides Domain are completely private and unreachable from outside.
• If the Uber Eats team needs ride data, they must invoke the Rides Domain Gateway API. They are strictly prohibited from calling internal driver matching or surge sub-services directly.
• Internal service implementations, database schemas, and protocols can be refactored or rewritten without breaking external consumers.

3. Layered Hierarchy:

DOMA organizes domains into strict functional layers with strictly unidirectional downward dependencies:

• Layer 1 - Edge Layer: Ingress API gateways (Zuul/Envoy) handling mobile TLS, authentication, and traffic routing.
• Layer 2 - Product Experience Layer: User-facing feature aggregation (e.g., Rider Mobile Experience, Restaurant Dashboard).
• Layer 3 - Core Business Domains: Reusable business capability engines (Rides Domain, Eats Domain, Payments Domain).
• Layer 4 - Infrastructure & Storage: Core compute, Kafka event brokers, Schemaless sharded databases, and networking. Rule: Lower layers can NEVER depend on or invoke higher layers, permanently eliminating circular dependency deadlocks.

Ride-sharing and food delivery require matching millions of riders, drivers, and restaurants in real time. Traditional latitude/longitude bounding box queries (ST_DWithin) in relational GIS databases (such as PostGIS) require expensive spatial trigonometry calculations (O(N) geometric distance formulas) that do not scale to millions of concurrent GPS updates.

To solve this, Uber open-sourced H3, a Hexagonal Hierarchical Spatial Indexing System:

Why Hexagons instead of Squares or Triangles?

• Equidistant Neighbors: A hexagon has 6 adjacent neighbors, and the distance from the center of a hexagon to the center of all 6 neighbors is strictly identical (\Delta d = constant).
• In contrast, a square grid has 8 neighbors, but diagonal neighbors are \sqrt{2} ≈ 1.414× farther away than orthogonal neighbors. Triangles have 12 neighbors with 3 different distance metrics. Hexagonal grids drastically simplify spatial radius searches, cluster calculations, and cellular smoothing algorithms.

Hierarchical Discrete Global Grid (16 Resolutions):

• H3 partitions the entire spherical surface of the Earth into hexagonal cells across 16 hierarchical resolution levels (Resolution 0 to 15):
  • Resolution 0: 122 base pentagons and hexagons covering global continents (~ 4,250,000 km² per cell).
  • Resolution 7: City borough / neighborhood scale (~ 5.16 km²).
  • Resolution 9: City street block scale (~ 0.1 km², hexagon edge length ≈ 174 meters)—ideal for real-time driver dispatching and localized surge pricing.
  • Resolution 15: Sub-meter precision (~ 0.89 m²).
• 64-bit Integer Cell IDs: Every H3 hexagon on Earth is encoded as a compact 64-bit integer (uint64). Finding all drivers within a 2-kilometer radius reduces to an instant O(1) bitwise ring expansion (h3.kRing(originCell, 2)) in RAM.

The Real-Time Matching Loop (DISCO / Supply-Demand Balancing):

1. GPS Telemetry Ingestion: Every driver app streams GPS coordinates every 4 seconds over persistent gRPC/WebSocket connections.
2. H3 Spatial Cell Mapping: The dispatch service converts lat/long coordinates into H3 Resolution 9 cell IDs and buffers them in an in-memory spatial index.
3. Proximity & ETA Optimization: When a rider requests a pickup, the dispatch engine executes a k-ring search to identify candidate drivers in adjacent H3 cells. It queries the routing engine to compute turn-by-turn road network ETAs using Contraction Hierarchies, matching the optimal driver in < 100 milliseconds.

Schemaless Storage Engine:

To handle billions of trip records without relational schema lockups, Uber built Schemaless, an append-only, fault-tolerant datastore layered on top of sharded MySQL:

• Immutable Sharded Cells: Data is organized into Cells, Keys, Column Families, and Timestamps. Records are strictly append-only; updates write a new timestamped version rather than overwriting rows.
• Zero-Downtime Shard Balancing: Sharded MySQL instances store hundreds of millions of trip records, decoupled from application schemas.