Inside the feature store powering Dropbox Dash's real-time AI

Search and agent ranking in Dropbox Dash must process thousands of feature lookups within sub-100ms.

To achieve this, Dropbox built a hybrid architecture centered on Feast instead of an off-the-shelf feature store. ML engineers focus on PySpark transformations, while offline processing is handled by Spark and cloud storage.

Online serving is handled by an internal system called Dynovault. It's attached to the low-latency search path, providing about 20ms of client-side latency while avoiding public internet calls.

Initial Python serving held up through parallelization, but JSON parsing and the GIL became bottlenecks. Dropbox rewrote the serving layer in Go to achieve true concurrency, cutting the added overhead to about 5-10ms and achieving p95 25-35ms.

The approach to maintaining freshness was also separated:

• batch ingestion: after large-scale transformation, only changed records are reflected in the online store
• streaming ingestion: fast signals like collaboration activity and content interactions are reflected in near real-time
• direct writes: results from separate pipelines are immediately written to the online store

Thanks to change detection, the write volume per batch dropped from hundreds of millions of records to under 1 million, and update time was reduced from over 1 hour to under 5 minutes. In the end, with the combination of Feast + Spark + Dynovault, Dropbox maintained consistency between training and serving while securing both fast ranking and low operational complexity.