SYSTEM Cited by 1 source

Uber Dispatch Service

Dispatch is Uber's rider-driver matching service — one of the two original 2011 Uber monoliths (Node.js + MongoDB-then-Redis), rewritten in 2014 into a series of microservices when the monolith became too entangled with mobile-gateway responsibilities and the simple "one rider, one driver" matching assumptions collapsed under city-scale growth. (Source: sources/2024-03-14-highscalability-brief-history-of-scaling-uber)

2014 rewrite — what changed

• Separation of concerns. Dispatch had been both the matching logic and the proxy routing all mobile-app traffic to other services. The mobile-gateway role moved to the new RTAPI Node.js layer. Dispatch kept only matching.
• Beyond "one driver, one rider". The new dispatch understood vehicle variety (multiple car types) and rider-need variety (airport queues, pool, etc.).
• Matching as a traveling-salesman-variant optimization. Dispatch now reasons about ETAs of currently-available drivers plus drivers who'll be available in the near future — a traveling-salesman-variant optimization over spatial + temporal state.
• Geospatial index with S2 shard key. To hold supply-position state, dispatch built a geospatial index using Google's S2 library with S2 cell IDs as the shard key — partitioning cities into areas of consideration. (H3 later replaced S2 as the hexagonal successor, which Uber open-sourced.)
• Ringpop for stateful Node.js sharding. Because the rewritten dispatch services remained Node.js and were stateful (sharded by S2 cell), Uber built the gossip-protocol-based Ringpop library to share geospatial + supply-positioning information across dispatch nodes without a central coordinator — the canonical geospatial-gossip-sharding shape.

2021+ Fulfillment Platform successor

By 2021 even the rewritten dispatch couldn't support the full range of use cases Uber had grown into (reservations, batching, airport virtual queues, three-sided Eats marketplace, Uber Direct package delivery). Uber ground-up rewrote the stack as the Fulfillment Platform on Google Cloud Spanner — a NewSQL bet for transactional consistency + horizontal scalability + low operational overhead.

Primary-source references from Clemm's retrospective:

• Fulfillment platform rearchitecture
• Scaling Uber's Real-time Market Platform — InfoQ talk on the dispatch rewrite.
• H3: Uber's hexagonal hierarchical spatial index

Seen in

• sources/2024-03-14-highscalability-brief-history-of-scaling-uber — the 2014 dispatch split is presented as one of the canonical pieces of Uber engineering lore.

Related

• systems/ringpop — gossip library that makes stateful Node.js sharding work.
• systems/s2-geometry — original geospatial shard key.
• systems/h3-geo — hexagonal successor to S2.
• systems/uber-rtapi-gateway — the sibling split-out of dispatch's mobile-gateway role.
• systems/uber-fulfillment-platform — the 2021 NewSQL-on-Spanner rewrite.
• companies/uber — origin org.
• concepts/traveling-salesman-problem — the shape of the matching optimization.
• concepts/geospatial-sharding — the sharding category.
• patterns/geospatial-gossip-sharding — the canonical pattern.