Stock MLOps: Building an End-to-End ML System for Stock Price Prediction

Ever trained a machine learning model in a class, watched it hit decent accuracy, and then... just left it sitting there in a Jupyter Notebook? No version control, no scheduled retraining, no monitoring — a model frozen in amber. That's the exact problem this project sets out to solve. It's called Stock MLOps, and the subject it predicts — stock prices — is honestly beside the point. The real goal is to take everything you'd learn in an MLOps course and wire it together into one living, breathing, end-to-end system.

So what does "end-to-end" actually mean here? Picture the full lifecycle: pulling in data, engineering features, training the model, tracking experiments, serving real-time predictions, and then deploying and monitoring the whole thing. From the outside, a user just visits a web page, types in a stock, and sees a predicted price plus a historical trend chart. But behind that simple page, a developer can retrain models on a schedule, compare experiments, watch for performance decay and data drift, and even trigger automatic retraining when things start to slip.

Here's the fun constraint: all of this runs on a single machine, orchestrated with Docker Compose. Not a sprawling cloud cluster — one box, cleanly divided into layers, and designed so it could be lifted onto an EC2 instance later without rethinking everything.

Let's talk about the stack, but in terms of jobs rather than logos. For infrastructure, Docker Compose ties it together, MinIO handles object storage, and there are two databases — PostgreSQL and ClickHouse — which we'll come back to, because how they're used is one of the more interesting design decisions. For the ML pipeline itself: FastAPI serves the APIs, Scikit-learn and Pandas do the modeling and data wrangling, and MLflow tracks experiments. Prefect 2 orchestrates the workflows. Monitoring is a trio — Evidently for drift detection, Prometheus for metrics collection, Grafana for the dashboards. And on the engineering side, GitHub Actions runs CI/CD, pytest handles testing, and black, flake8, and pre-commit keep the code clean. The frontend is Vite and React, the backend is a handful of FastAPI containers, and Nginx sits out front serving static files and acting as a reverse proxy.

Now, that data layering I promised. A lot of student projects cram everything into one database and call it a day. This one deliberately splits it. There's a raw store — that's PostgreSQL, and it holds exactly what the ETL process pulls in, untouched. Then there's ClickHouse, which holds the cleaned, transformed data and acts as the analytical query layer. The reason that matters: ClickHouse is built for OLAP — fast analytical reads over big columns of data — so both inference and training pull their features from there, while PostgreSQL keeps the messy original safe. The data itself comes from Yahoo Finance — historical prices for Taiwan and US stocks, things like TSMC and Apple — and after transformation it lands as Parquet files, a compact columnar format that's cheap to read.

So how does the model actually stay alive over time? Prefect is the conductor. On a schedule, it kicks off the ETL and training pipelines. When training finishes, the results get logged to MLflow and registered as a versioned model — so you always know which model is which, and you can roll back. FastAPI exposes two key endpoints: one to predict, one to train, with Celery handling the training as an async background task so nobody's HTTP request hangs while a model trains. Meanwhile Evidently is computing drift metrics and pushing them into Prometheus, and Grafana turns all of it — prediction accuracy, drift, system health — into dashboards you can actually watch.

One nice detail: MLflow here wears several hats at the data level. A PostgreSQL database stores the model metadata, there's a separate internal database for MLflow's own bookkeeping, and the actual model artifacts — the trained files themselves — live in MinIO object storage. Metadata in a database, big binary blobs in object storage. That's exactly the separation you want.

Let's zoom in on Nginx, because it's doing more than the usual reverse-proxy job. It's actually splitting traffic across two backend instances with different weightings depending on what kind of request comes in. Prediction traffic leans heavily on backend one — about seventy percent there, thirty percent to backend two. Training traffic flips that: mostly backend two. General API calls get split evenly, fifty-fifty. And any WebSocket connection gets routed to a dedicated monitoring service. So it's not just load balancing — it's role-aware load balancing, sending different workloads to different places.

Let me walk you through the whole flow as one picture. A user's browser talks to Nginx over HTTP or WebSocket. Nginx serves the React build for static content, and routes API calls to those two weighted backend pools. Off to the side, Prefect runs the ETL — dropping raw data into PostgreSQL and cleaned data into ClickHouse. The backends query their features from ClickHouse and, when a training job comes in, push a task onto Redis. A Celery worker picks that task up, reads from ClickHouse, trains the model, tracks it in the MLflow registry — which stores artifacts in MinIO and metadata in PostgreSQL. And the monitoring corner has Evidently feeding Prometheus feeding Grafana, plus a metrics publisher pushing updates into Kafka every five seconds. Everything has its lane.

That Kafka piece leads to my favorite part: real-time push. Monitoring here isn't a dashboard you refresh and wait on. The system streams data live through Kafka with two dedicated services. One, the metrics publisher, grabs metrics every five seconds and drops them onto a Kafka topic. The other, the WebSocket monitor, consumes from Kafka and simultaneously pushes both predictions and metrics out to the frontend over WebSocket. The payoff is that prediction results and system metrics show up on the screen almost instantly — no polling, no hammering the server with "anything new yet? anything new yet?"

And then there's the engineering discipline, which is what separates a demo from something maintainable. There's real testing — pytest covers unit tests for training and prediction, plus integration tests against the actual predict and train APIs. Formatting and hooks are enforced with black, flake8, and pre-commit, so bad style never even reaches the repo. A Makefile wraps the common commands so setup and workflows stay consistent across machines. And GitHub Actions runs the full CI and CD pipeline, even firing a Discord notification through a webhook when something deploys. Getting it running yourself is refreshingly boring, in the good way: spin up a virtual environment, install the requirements, run docker compose up to build everything, and then a single make command to train a model or kick off the Prefect workflow.

So let me leave you with the three things that actually matter here. First: the value was never the stock prediction accuracy — it's the wiring. This project takes a model that would've died in a notebook and gives it a full production nervous system. Second: notice the recurring pattern of clean separation — raw data versus cleaned data, metadata versus artifacts, prediction traffic versus training traffic. Good MLOps is mostly about drawing the right boundaries. And third: the lifecycle only closes because of feedback loops — Prefect schedules retraining, Evidently watches for drift, and monitoring flows back to trigger the next round. That loop is what makes a system sustainable instead of a one-time experiment. If you've got a model stuck in a notebook and you're wondering what "production-grade" really looks like, this is a clean skeleton to study.