DoorDash built an end-to-end machine learning platform around feature engineering, training, serving, forecasting, and model monitoring.
2
The platform team works with data scientists through a machine learning council, customer wishlists, workshops, surveys, and regular communication.
3
DoorDash learned to start with a specific customer problem, build a small solution around it, and expand only after users adopt it.
Summary
Hien Luu and the DoorDash Leads describe a machine learning platform built for logistics, search, recommendations, advertising, forecasting, fraud, and delivery estimates. The platform covers feature engineering, offline and online feature access, model training, model serving, experimentation, forecasting, monitoring, and a central ML portal. DoorDash combines open source, commercial products, and in-house systems. Its serving layer handles very large prediction volumes under strict latency and availability requirements, while the feature store has gone through several storage implementations. The team says platform adoption depends on working with data scientists throughout planning and delivery. A machine learning council, quarterly customer requests, workshops, surveys, and migration support keep the platform aligned with users. Their advice is to balance velocity with reliability, offer enough flexibility without creating fragmentation, and solve one concrete problem fully before expanding the platform.
DoorDash uses machine learning across the operating business
Hien Luu says machine learning supports DoorDash's logistics infrastructure, including assigning orders to Dashers and helping deliver them. The company also uses it for search, recommendations, ads, promotions, forecasting, and fraud. DoorDash's estimated delivery time is another demanding use case because the displayed number of minutes depends on machine learning. The breadth of these applications explains why the platform has to support several types of teams and workflows rather than a single modeling pattern.
The platform covers the full path from features to production models
Hien Luu describes the goal as an end-to-end platform for applied machine learning at scale. The system covers feature engineering, model training, model serving, forecasting, and model durability. The team follows principles described as "dream big, start small" and customer obsession. Its stack combines commercial vendor products, open source systems, and DoorDash-built components. The platform is intended to give data scientists a standard path so they can focus on business logic instead of repeatedly solving infrastructure problems.
The feature store evolved as production volume grew
DoorDash supports feature experimentation, deployment, warehousing, compute, and production access for both offline and online use. The team first used Redis or ElastiCache and later expanded the system. The discussion says the feature store handled billions of updates daily and had more recently reached tens of billions of updates per day. On the serving side, the feature store remained a major latency bottleneck. The team says about 80 percent of serving latency came from calls to the feature store, which led to repeated storage and architecture changes, including CockroachDB.
Model serving has strict latency, availability, and scale requirements
The model serving platform was one of DoorDash's first machine learning platform components. DoorDash Leads describe a service built inside the company's microservice architecture because that environment provided established infrastructure practices and optimizations. The service targeted four nines of availability and latency in the range of one millisecond or less per prediction. It handled around 100 billion predictions per day. Because of those requirements, DoorDash built the serving system and its integrations in-house, later also bringing more of the response streaming path in-house.
The ML portal brings scattered model workflows into one place
DoorDash's internal ML portal is intended to be the home page for data scientists. It brings together model and feature repositories, interpretability, monitoring, lineage, alerts, workflow status, and links to deeper tools. The team is also adding actions such as training and deploying models directly from the interface. Before this, data scientists had to visit separate locations for orchestration status, metrics, and other information. The portal gives them a model home page with the basic information and workflows needed for common tasks.
Experimentation is being built into the serving workflow
DoorDash has an internal experimentation platform called Curie. The team is integrating it with the machine learning platform so data scientists can test new models without depending on product engineering to set up each experiment. Previously, data scientists often had to create experimentation frameworks themselves. The new approach places experiment setup in the serving layer and lets users configure it through existing applications and workflows. The stated goal is to make experimentation available through a few interface actions instead of requiring repeated custom engineering.
Platform adoption depends on regular contact with data scientists
Hien Luu says the biggest lesson from earlier platform work was organizational rather than technical. At DoorDash, a machine learning council brings together data scientist representatives and leaders from teams that use machine learning heavily. The platform team shares updates every two weeks, discusses vendor evaluations openly, plans with customers each quarter, attends their workshops, and presents new features to the data science community. The team also invites data scientists to informal lunches. These practices are meant to remove a "we versus them" attitude and make platform planning a shared activity.
DoorDash avoids overbuilding by starting with customer problems
DoorDash Leads say the platform team does not build components simply because they seem interesting. It looks for teams with an immediate problem, builds a small solution, and uses adoption to decide what to expand. This approach limits over-design and prevents the team from spending resources on systems that do not solve a real need. The inference service grew first because serving was where customers had the largest problems. The team also combines a longer-term strategy with quarterly customer requests, choosing work that helps current users while moving toward the desired future platform.
The team measures system health and user experience together
DoorDash tracks platform health through model counts, online service availability, feature scale, ML portal usage, system scalability, and cost per prediction or delivery. It also monitors prediction latency and availability, along with statistical information about model inputs and outputs, such as percentiles, averages, and the number of zero values. The team surveys customers about every six months to measure satisfaction with platform components and collect free-text feedback. This gives the platform team both operational measures and direct evidence about whether the services meet data scientists' expectations.
"The biggest thing that I see is it's not so much about technology. It's how do we really engage with our data scientist community to help shaping the direction of the platform."Hien Luu16:16
Who should watch
You are building an internal machine learning platform and need to decide which parts should be homegrown, adopted from open source, or bought from vendors.
Your data science users are bypassing the platform, and you want practical ways to involve them in planning, migration, and feature design.
You need examples of platform metrics that cover serving reliability, model behavior, cost, usage, and customer satisfaction.
