Uber DOMA & H3 Geospatial Lab (Interactive)
Encapsulate 4,000 tangled services behind domain gateways and sweep H3 resolution rings. Measure how Domain-Oriented Microservice Architecture collapses cross-domain edges, then explore H3 hexagon areas and k-ring cell counts that power rider-driver matching across 10,000 cities.
Uber DOMA & H3 Dispatch Lab
Contain the 4,000-service Death Star behind domain gateways, then size H3 hexagon resolutions for sub-100ms rider-driver matching.
How It Works Under the Hood
Uber's first SOA grew into roughly 4,000 microservices calling each other directly into a dependency hairball. DOMA imposed a second-level structure: about 70 top-level domains, each fronted by a single domain gateway that owns its gRPC contracts, so cross-domain traffic passes through two hops instead of an unmanaged mesh and team ownership matches the graph. H3, Uber's open-source hexagonal spatial index, quantizes GPS into cells whose area divides by 7 per resolution step, letting matching compute supply and demand over k-rings of neighbors in sub-milliseconds.
Core Architectural Principles
- Domain gateways replace N x M ad-hoc service edges with per-domain encapsulation, cutting inter-domain coupling and blast radius.
- H3 cell area shrinks 7x per resolution level: resolution 9 covers blocks, resolution 6 covers neighborhoods.
- k-ring growth formula 1 + 3k(k+1) counts the hexagons queried for a radius-k supply sweep around a pickup point.
For Uber-style geospatial design, name the index explicitly: "H3 hexagons with a k=1 ring for nearby drivers, indexed in Redis as (cell_id, driver_id)." Justify DOMA as the answer to microservice sprawl — domain gateways give you contracts, ownership, and failure isolation at organizational scale, which is exactly the 1,000-engineer problem.
DOMA adds a gateway hop and governance cost to buy dependency clarity; H3 trades exact geography for O(1) cell lookups with predictable ring expansion.