David Hershey builds a movie recommender in stages, moving from daily batch recommendations to online ranking based on the movie a user just watched.
2
Tecton turns Snowflake data into features and makes those features available for both model training and online inference.
3
The real-time system uses candidate generation, filtering, and ranking, with approximate nearest neighbors for similar movies and parallel feature requests to reduce latency.
Summary
David Hershey demonstrates an end-to-end movie recommendation system built with Tecton and Snowflake. The system starts with daily, precomputed recommendations for each user. Movie metadata and MovieLens ratings live in Snowflake, Tecton computes features, TabNet predicts ratings, and the results are served through a Flask backend. He then adapts the design for online recommendations. When a user finishes a movie, approximate nearest neighbors generate candidates, recent viewing history removes unsuitable choices, and a model endpoint ranks the remaining movies. Tecton supplies the online feature vectors needed by the ranking step. Hershey also shows how asynchronous requests reduce the cost of retrieving many candidate feature vectors. The final stage, which he describes without implementing, adds fresh application activity such as clicks, trailer views, or recent viewing behavior. He is direct about the limits of the demo, including Flask endpoints that would not scale, while arguing that incremental changes make real-time systems easier to build.
A feature platform manages the path from raw data to model inputs
David Hershey describes Tecton as a feature platform that takes data from the places where it lives, transforms it into machine learning features, and provides access during training and serving. It also manages transformation logic and the pipelines that populate the feature store. In the demo, most transformations run in Snowflake SQL. Tecton therefore covers more than storing already-computed features. It connects raw movie and rating data to the model inputs used in both batch inference and online inference.
The first recommender uses daily batch predictions
The initial website gives each user a fixed list of precomputed movie recommendations. Movie information and historical user ratings are loaded into Snowflake. Tecton computes the features, a TabNet model predicts ratings, and batch inference runs on a schedule. The predicted user-movie ratings are written back to Snowflake, where the highest-scoring movies become the recommendations returned by a Flask backend. Hershey notes that scheduled recomputation allows the system to account for new movies, new users, and changes in popularity.
Simple feature transformations are enough for the first model
The demo begins with two feature groups. Movie genres arrive as pipe-separated strings, so a Snowflake SQL transformation turns them into one-hot encoded indicators such as whether a movie is an action or animation movie. The second group captures a user's historical preferences by calculating average ratings for different genres over a two-year window. Tecton joins the ratings and genre data and performs the window aggregation. Hershey keeps the feature set small so the system can be built and understood before adding more complexity.
Online recommendations narrow the search before ranking
When a user has just watched a movie, the system cannot score every movie available. It first generates a smaller candidate set, then filters out movies the user recently watched, and finally ranks the remaining candidates. Candidate generation uses similar movies, while filtering uses recent viewing history. Ranking sends feature vectors for the candidates to the model endpoint and sorts them by predicted rating. The stages can support different goals, such as getting a user to click or buy something, rather than only predicting a rating.
Approximate nearest neighbors make similarity lookup practical
Hershey represents each movie as a column in a user-by-movie rating matrix and measures similarity between those columns. The vectors are large, with one dimension for each active user, so calculating exact nearest neighbors across all movies would take too long to repeat every day. He uses Annoy to build an approximate nearest-neighbor model. For example, Toy Story's nearest neighbors include other Toy Story films and Monsters, Inc. The resulting list of 100 similar movies for each movie is stored in Snowflake and then ingested into Tecton for fast serving.
The ranking service needs many online feature lookups
For each candidate movie, the backend asks Tecton for a feature vector containing movie attributes and the user's historical genre preferences. With 100 candidates, this means about 100 feature requests before the model can rank them. The demo notebook makes those calls serially, which is slow. Hershey's production-style Flask application uses asynchronous methods to issue the requests in parallel. He reports that this reduces the feature retrieval step from about a second in the notebook to about 100 milliseconds in the application.
Fresh application activity is the next step beyond batch features
The implemented online system reacts to the movie a user just watched, but its features still come from historical batch data. Hershey says the next stage is to ingest real-time activity from the application, such as spending time looking at action movies or watching a trailer. Tecton can consume streaming sources or events sent directly by the website, transform them into features, and make them available to the model. He describes the last 90 seconds of a user's activity as especially useful for recommendations, while acknowledging that this requires connecting to production systems such as Kafka or online databases.
Incremental construction keeps real-time work manageable
Hershey says the move from batch recommendations to online recommendations required only a small set of new components: a nearest-neighbor lookup, a model endpoint, and a more involved backend. He estimates that he built the demo in a day and a half. The Flask services would not scale as production systems, and he is open about the complexity left out. His approach is to divide the system into candidate generation, filtering, ranking, and data-serving pieces rather than trying to reproduce a mature recommender all at once.
