# feature-store Published articles for feature-store. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Creating an AI Platform for classic ML online inference DevFeed: [Creating an AI Platform for classic ML online inference]() Original publisher: [Read original article]() Author: Rohith Leeladharan Published: 2026-09-10T07:26:46Z Content type: tutorial Language: en Sources: [Amex GBT Technology]() Topics: [AI Platform](), [Inference](), [MLOps](), [Machine learning](), [model-deployment]() Tags: [ai](), [ai-platform](), [ai-platform-engineering](), [deploy](), [experiments](), [feature-store](), [inference](), [machine-learning](), [ml](), [mlops](), [monitoring](), [predictions]() ### AI overview This article describes how American Express Global Business Travel built an AI platform for deploying classic machine-learning systems and supporting online inference. It explains the platform's requirements--simplicity, self-service, experimentation, and continuous improvement--and details the pre-process, predict, post-process pattern used by inference engines. ### Source excerpt Introduction In 2021, we were given the mission to have AI Systems running in production. The team, instead of just following a classical MLOps process, that involves transforming a Jupyter notebook into a product running in production, decided to go further by creating a platform to deploy AI systems in production. The team decided the platform should respect these requirements: Simplicity: The code powering AI systems should be simple, readable, and easy to maintain -- less intricacy means fewer bugs in production and greater reliability. Self-service: Anyone should be able to build and deploy AI systems autonomously, without depending on a central team. Experimentation: The platform should make it easy to run and iterate on experiments. Continuous improvement: Data related to events and interactions within AI systems must be captured, enabling monitoring and continuous improvement over time. In this article, we will walk through the work done to build a platform that fulfills these four requirements. Background At American Express Global Business Travel, we use machine learning (ML) models for a variety of user experiences like ranking hotel and flight search results. Our ML models are wrapped in inference engines that handle both pre-processing of input data before we run a prediction with the model, and post-processing of output data before returning the output to the caller. The overall flow looks something like this: Figure 1: Handling an inference request A client service that would like the ML model's predictions provides necessary context about the request like which user the request is for. Then, optionally, the inference engine fetches any necessary features for inference from our feature store [part 1][part 2]. Finally, it pre-processes the data, runs the predictions using the trained ML model, and does any necessary post-processing of the model output before returning the response to the caller. We call this the pre-process, predict, post-process patter ## Distilling Long-Tail User Behavior into Scalable Embeddings for Job Search DevFeed: [Distilling Long-Tail User Behavior into Scalable Embeddings for Job Search]() Original publisher: [Read original article]() Author: Marsan Ma Published: 2026-06-03T23:28:10Z Content type: article Language: en Sources: [Indeed]() Topics: [recommendation systems](), [Embeddings](), [Deep learning](), [Latency](), [Job]() Tags: [big-data](), [data-science](), [deep-learning](), [embeddings](), [engineering](), [feature-store](), [job-search](), [latency](), [machine-learning](), [performance](), [ranking]() ### AI overview Indeed describes a user behavior modeling system for job search that learns from long-term user histories offline, distills them into fixed-length embeddings, and serves them through a feature store for use by online ranking and recommendation models. The approach is designed to preserve rich behavioral signals while meeting latency and cost constraints. ### Source excerpt Authors : Marsan Ma, Nikhil Lopes, Raj Amrit, Hong Lu, Dipankar Biswas, Trent KyonoLeadership: Iris Wang, Madhu Kurup Recommendation and ranking systems power many of the most important experiences on large internet platforms. Yet the models that run in production are rarely the largest models we can train. They are usually compact, latency-sensitive supervised models [...] ## Using Dolt's Versioned SQL Database for Feature-Store Point-in-Time Reads DevFeed: [Using Dolt's Versioned SQL Database for Feature-Store Point-in-Time Reads]() Original publisher: [Read original article]() Published: 2026-05-15T00:00:00Z Content type: opinion Language: en Sources: [Alex Korbonits]() Topics: [feature-store](), [Git](), [reproducibility](), [Databases](), [SQL]() Tags: [dedupe](), [feature-store](), [git](), [reproducibility](), [rfc](), [row-number](), [sql](), [sql-database]() ### AI overview This article describes a prototype Feast offline-store plugin backed by Dolt, a version-controlled SQL database. It argues that Dolt's revision-based reads can provide point-in-time feature retrieval and reproducible training snapshots without the usual append-only log deduplication CTEs. Tests on toy datasets produced identical results with shorter queries, though the article presents this as an early spike rather than a production benchmark. ### Source excerpt A weekend spike asked whether Dolt's AS OF reads could replace the ROW_NUMBER dedupe at the heart of every feature store's point-in-time join. Four weeks later, the RFC is quiet and the plugin's get_historical_features works end-to-end against a live Dolt server. Notes on building anyway. ## How Whatnot's Hourly ML Feature Pipeline Safely Handled a Failed Update DevFeed: [How Whatnot's Hourly ML Feature Pipeline Safely Handled a Failed Update]() Original publisher: [Read original article]() Author: Whatnot Engineering Published: 2026-05-07T16:01:01Z Content type: article Language: en Sources: [Whatnot Engineering]() Topics: [Machine learning](), [recommendation systems](), [datasets](), [data](), [real-time](), [Processes]() Tags: [ai](), [data](), [data-engineering](), [feature](), [feature-engineering](), [feature-store](), [machine-learning](), [ml](), [pipeline](), [ranking](), [real-time](), [recommendation-system](), [recommendations](), [run]() ### AI overview Whatnot describes how its hourly ML feature pipeline handled a bad pull request that caused a feature group to produce zero rows. The online feature store served last-known-good features for up to two days, anomaly monitors detected the row-count drop, and the team reverted the change before the freshness gap became significant. The post shares lessons about safe degradation and operating frequently updated recommendation features. ### Source excerpt David Kawashima, Miguel Fernandez-Montes Cuberta, Ford Bohrmann | Discovery A bad PR went out just as our hourly feature pipeline was about to run. The pipeline was responsible for recomputing fresh user behavior signals used in livestream ranking on the home feed. These features capture recent user intent: watches, bids, orders aggregated across users, sellers, and categories. A missed feature update means that the system stops responding to user signals immediately. This PR release caused one of our feature groups to suddenly produce zero rows ... but nothing broke! Even though a critical feature group for the model stopped updating, the online feature store continued serving the last-known-good features, buffered by a 2-day TTL and nothing broke explicitly. Our anomaly monitors went off immediately, flagging the drop in row counts. The team identified the bad change and reverted it before the freshness gap grew large enough to matter. No corrupted data reached production. The system absorbed the failure and degraded safely. This graceful degradation didn't happen by accident; it was the result of hardened processes from years of lived experience, seeing the way these systems can degrade in obvious or subtle ways. In this post, we share some of those lessons learned. The system: hourly feature pipeline Whatnot is a highly dynamic marketplace where buyers' preferences change at a moment's notice. A buyer might research a laptop, join a football-card break a few hours later, and buy chocolate before logging off for the night. Daily feature updates capture long-term preferences but miss intra-day shifts. To keep up with these rapidly changing buyer interests (in 2025) we moved from daily to hourly updates for features that power our ML feed ranking models. Fresher features are a critical component for capturing the live nature of the Whatnot marketplace, where the inventory available to purchase changes in real time. Moving from daily to hourly updates was a meaningful ## Engineering Features at Scale: Inside the Darwin Feature Store DevFeed: [Engineering Features at Scale: Inside the Darwin Feature Store]() Original publisher: [Read original article]() Author: Dream Blog Published: 2026-01-27T15:38:25Z Content type: article Language: en Sources: [Dream11 Engineering]() Topics: [Feature Engineering](), [Low Latency](), [Apache Cassandra](), [Machine learning](), [Open Source]() Tags: [cassandra](), [data](), [engineering](), [feature-engineering](), [feature-store](), [inference](), [kafka](), [latency](), [machine-learning](), [offline](), [open-source](), [pipelines](), [software-engineering](), [tech]() ### AI overview Dream Horizon's Darwin Feature Store is an open-source, low-latency feature platform designed to support real-time machine learning and offline training at Dream11. The article describes the challenges that led to its development, including batch-only pipelines, manual schema changes, and scaling issues. It reports serving more than 200 million feature requests per minute with p99 read latency below 5 milliseconds and no production incidents over the preceding year. ### Source excerpt By Mohit Jain and Ujjwal Bagrania Dream Horizon, our open-source effort to make Dream11's battle-tested tech available to every developer, brings you the Darwin Feature Store -- a unified, low-latency feature platform built to power real-time ML at scale, and shaped to help teams build, manage, and trust features in production. Explore the Darwin Feature Store here. At Dream11, data and ML have always powered how millions of users experience sports in real time. From personalisation and relevance to ensuring efficiency under peak match traffic, ML sits deep in the critical path of the product. But models are only half the story. The real challenge is managing features -- how they're defined, versioned, and accessed consistently across training and live traffic, especially under peak sports pressure. And at the scale we operate at, feature access doesn't mean the occasional lookup; it means hundreds of millions of requests per minute, spanning both real-time inference and offline training pipelines. As Dream11 grew, feature engineering stopped being something we could manage with pipelines and tables, and became infrastructure that everything else depended on. That shift forced us to build the Darwin Feature Store: a system designed not just to tackle sports-scale traffic, but to make feature engineering predictable, reliable, and developer-friendly in production. Today, that translates into serving 200M+ feature requests per minute, delivering p99 read latencies under 5 ms, and doing so reliably through the most demanding live sports moments, without a single production incident over the last year. In this post, we'll walk through how we built the Feature Store, and what it takes to serve features reliably. The Early Days: Batch-Only, Fragile, and Manual Before the Darwin Feature Store existed, our feature engineering was mostly a few pipelines, a lot of Cassandra tables, and an increasing number of engineers building ML models. Here's what the first version looked li ## Introducing Glassdoor's ML Registry: A Centralized Artifact Management Solution DevFeed: [Introducing Glassdoor's ML Registry: A Centralized Artifact Management Solution]() Original publisher: [Read original article]() Author: Rich Papalia Published: 2023-08-30T21:20:29Z Content type: article Language: en Sources: [Glassdoor Engineering]() Topics: [Machine Learning & Artificial Intelligence](), [Open Source](), [Development](), [Amazon SageMaker AI]() Tags: [aws](), [configuration-management](), [feature-store](), [lifecycle](), [machine-learning](), [machine-learning-platform](), [open-source](), [pipelines](), [registry]() ### AI overview Glassdoor describes its newly open-sourced ML Registry, a centralized service for managing machine-learning artifacts and related metadata. The registry is intended to provide a single source of truth and consistent access across teams and applications, integrating with other tools and services. ### Source excerpt Photo by Ryunosuke Kikuno on UnsplashGlassdoor's Machine Learning Engineering and Platform Team As part of Glassdoor's journey to becoming an ML-driven company, we've created an exceptional Machine Learning Engineering and Platform team, (see our blog about building this team here) dedicated to developing the foundational infrastructure for all of our ML initiatives. We've strategically built our ML platform by utilizing a combination of buying, building, and adopting from existing open-source solutions. This approach has allowed us to leverage the best of all worlds. Our team has had the opportunity to build numerous tools from scratch, including data pipelines, human-in-the-loop tools, and more. We've also built on top of existing tools like AWS Sagemaker to incorporate powerful in-house customizations into our feature store. We have more exciting plans in flight, such as building a new recommendations platform, further open-source contributions from our platform, and continuing to build on the foundation which we've established. Today, we'll delve into our newly open-sourced ML Registry. What is an ML Registry? The ML lifecycle encompasses far more than just model development. Once a model is built, many questions arise: Where does it reside? How do we access it? What if updates or versioning are needed? Where can we store the metadata describing the model? And what about other non-model artifacts? How can we efficiently manage all of this? Enter the ML Registry. Glassdoor's ML Registry is a centralized management service for ML artifacts and all related metadata. It serves as the single source of truth for all data pertaining to ML, enabling uniform and reliable access to this data across diverse teams and applications. It seamlessly integrates with other tools and services and provides robust, feature-rich functionality. Choosing Between Buying and Building, What Differentiates Our ML Registry? While several paid and open-source model registries already exist, ## Using Tinybird as a serverless online feature store DevFeed: [Using Tinybird as a serverless online feature store]() Original publisher: [Read original article]() Author: Dan Chaffelson Published: 2023-06-27T00:00:00Z Content type: comparison Language: en Sources: [Tinybird]() Topics: [Serverless](), [SQL]() Tags: [compare](), [feature-store](), [scalable-analytics-architecture](), [serverless](), [sql]() ### AI overview This article compares Tinybird with feature stores as a serverless online feature-store solution, claiming that Tinybird performs the same job using SQL and may cost less. ### Source excerpt Feature stores cost thousands per month. Tinybird does the same job with SQL you already know. Compare the results yourself.