Uber & DoorDash (Michelangelo, DeepETA, marketplace & pricing, fraud, Eats/search recsys, document verification; dispatch, ETA, switchbacks)¶

Why this matters at staff level. Uber and DoorDash are two-sided (or three-sided) marketplaces where ML decisions move physical supply: ETAs feed dispatch and pricing, dispatch feeds courier earnings and customer wait, and every experiment leaks across the marketplace. Interviews test whether you can reason about forecasting under a routing engine, marketplace experiments that break i.i.d. assumptions, fraud with adversaries and human review, and platform work that lets hundreds of models ship. Strong signal is grounding designs in their published systems: Michelangelo, DeepETA, Uber's experimentation platform posts; DoorDash's dispatch, switchback, Sibyl and feature-store posts.

Sources in this chapter

Claims are tied to public Uber and DoorDash engineering posts and papers, cited by exact title, venue and year in Sources. URLs are omitted where they could not be verified in the build environment (STYLE.md §4). Anything not in a public source is marked inference.

1. The business in one paragraph¶

Uber matches riders with drivers and eaters with couriers and restaurants; DoorDash matches consumers, merchants and Dashers. Both earn a take rate on transactions, so unit economics hinge on ML: predicting ETAs and prep times (which set expectations, prices and dispatch), setting prices and incentives that balance supply and demand, dispatching efficiently (an optimisation problem fed by ML predictions), ranking restaurants and dishes, catching fraud on both sides (payments, promotions, fake accounts, GPS spoofing), and verifying identity documents for onboarding. Uber built one of the first broadly described ML platforms (Michelangelo, 2017) and later documented DeepETA; DoorDash has published on dispatch, switchback experiments, its Sibyl prediction service, feature store and ETA models.

2. The ML problems that define the company¶

Problem	Why it is hard	Public evidence
ETA prediction	Routing engines give physical estimates; residual error depends on traffic, pick-up behaviour, restaurant prep; latency budget is tight; billions of predictions per day	"DeepETA: How Uber Predicts Arrival Times Using Deep Learning" (Uber, 2022); DoorDash posts on ETA prediction and long-tail events (2023–2024)
Dispatch	Assignment under uncertainty, batching, future supply; ML predictions feed an optimiser	"Next-Generation Optimization for Dasher Dispatch at DoorDash" (2020); "Using ML and Optimization to Solve DoorDash's Dispatch Problem" (2021)
Marketplace experiments	Treatment leaks through shared supply; standard A/B is biased	"Experimentation in a Ridesharing Marketplace" (Lyft, 2018); "Switchback Tests and Randomized Experimentation Under Network Effects at DoorDash" (2018); "Analyzing Switchback Experiments by Cluster Robust Standard Error" (DoorDash, 2019)
Forecasting	Demand by hex and time; extreme events	"Forecasting at Uber: An Introduction" (2018); "Engineering Extreme Event Forecasting at Uber with Recurrent Neural Networks" (2017)
Fraud and safety	Adversaries adapt; payments, promo abuse, account takeovers; humans in the loop	"Project RADAR: Intelligent Early Fraud Detection System with Humans in the Loop" (Uber, 2022); DoorDash fraud posts
Identity and document verification	Driver onboarding requires licences, insurance; selfie verification; OCR on noisy phone photos	Uber "Real-Time ID Check" (product, 2016 onward); Uber's document verification is product-level public, model details inference
Eats / search / recommendations	Cold-start restaurants, geo-constrained candidates, dish-level intent	"Food Discovery with Uber Eats: Using Graph Learning to Power Recommendations" (2019); "Innovative Recommendation Applications Using Two Tower Embeddings at Uber" (2023); "Things Not Strings: Understanding Search Intent with Better Recall" (DoorDash, 2020)
ML platform	Feature store with online/offline parity, model registry, low-latency serving	"Meet Michelangelo" (2017); "Scaling Machine Learning at Uber with Michelangelo" (2018); "From Predictive to Generative: How Michelangelo Accelerates Uber's AI Journey" (2024); "Meet Sibyl" (DoorDash, 2020); "Building a Gigascale ML Feature Store with Redis…" (DoorDash, 2020); Fabricator and Riviera posts (2021–2022)

3. The stack as publicly described¶

flowchart LR
  subgraph Uber
    UL[Trip, app & map events] --> UP[Palette feature store - offline Hive + online Cassandra]
    UP --> UT[Michelangelo training - Spark, XGBoost, DL]
    UT --> UR[Model registry & deploy]
    UR --> US[Online prediction service]
    RE[Routing engine ETA] --> DE[DeepETA: residual over routing ETA]
    US --> DE
    DE --> MP[Matching, pricing, dispatch]
    US --> FR[Fraud: RADAR + human review]
    US --> EA[Eats ranking: graph & two-tower]
    XP[Experimentation platform - switchbacks, synthetic control] -.-> MP
  end
  subgraph DoorDash
    DL[Order, Dasher & merchant events] --> DF[Feature store on Redis - Riviera / Fabricator]
    DF --> DS[Sibyl prediction service]
    DS --> DD[Dispatch optimizer - assignment under ML-predicted prep & travel times]
    DS --> DE2[ETA models - multi-task, probabilistic]
    DS --> DSR[Search & notifications]
    DX[Switchback experiments] -.-> DD
  end

What is public: Michelangelo's components, a feature store (Palette) with offline and online stores, Spark-based training, model management and a low-latency prediction service (2017–2018 posts); DeepETA as a transformer-style residual model on top of a routing engine ETA (2022); Uber's experimentation platform internals (2018), and Lyft's account of network interference in a ridesharing marketplace (2018); DoorDash's dispatch optimisation fed by ML estimates (2020–2021), Sibyl as the prediction service (2020), Redis-based feature store (2020), Riviera and Fabricator for feature engineering (2021–2022), and switchback experimentation with cluster-robust inference (2018–2019). Inference: current model families per surface and the exact integration between prediction and optimisation are not fully published.

4. Deep dives¶

4.1 DeepETA: learning the residual of a routing engine¶

The problem. Routing engines compute travel time from map segments, but real arrival times deviate: traffic, pick-up dwell, route deviations, driver behaviour. Uber needed a global model, low latency, and calibrated outputs for many consumers (rider ETA, matching, pricing, Eats).

The approach (per the 2022 post). DeepETA predicts the residual between the routing-engine ETA and the actual duration, not the ETA itself, which keeps the physical prior and lets the model focus on systematic bias. Inputs are embedded: continuous features are quantised into buckets and embedded, geospatial features are embedded via multiple resolutions of hexagonal (H3-style) grids with feature hashing, and a self-attention encoder captures interactions across the trip's features (origin, destination, time, request type). To hit a strict latency budget the encoder uses a linear attention variant, and a small bias-adjustment decoder produces per-segment (e.g., per-request-type, per-city) corrections; the post describes calibration and an asymmetric loss so that early and late errors can be weighted differently by consumer. Training is on a large trip corpus and the post discusses that the model replaced an XGBoost residual model.

Math link. Residual learning: \(\hat T = T_{\text{route}} + f_\theta(x)\); with an asymmetric loss \(\ell(r) = |\tau - \mathbb{1}[r<0]|\cdot|r|\) you get the quantile regression at level \(\tau\), see forecasting & ETA design and efficient attention for linear attention.

The trade-off. Predicting the residual constrains the model but makes it robust and easy to fall back from; linear attention loses some expressivity for latency; discretising continuous inputs trades resolution for learnable embeddings that the post reports outperformed raw inputs.