From Data to ML Model Serving: A Simple Local MLOps Setup
MLOPS Architecture

From Data to ML Model Serving: A Simple Local MLOps Setup

Why I built this project

Many people learn machine learning, but very few get a chance to understand how machine learning systems are actually built and maintained in real-world environments. This project is my way of creating a local and straightforward MLOps example that anyone can run on their laptop.

My goals were:

  • Keep everything small and easy to understand
  • Use tools that many companies use
  • show the real steps behind an ML system
  • make it possible for learners to experiment safely

The GitHub repository is here: https://github.com/ankit-khare-2015/local-mlops-fraud-classifier


Use case: Fraud detection

To make the project more practical, I selected an everyday use case: predicting whether a transaction is fraudulent.

The dataset is synthetic. It is generated in a way that follows typical real-world patterns. The fraud probability increases when:

  • The transaction amount is high
  • The user is on a VPN
  • The transaction happens at night
  • The customer has had past chargebacks
  • The transaction comes from certain countries
  • The merchant is risky

This makes the model output meaningful and provides a reasonable basis for demonstrating MLOps processes.


What MLOps ideas does this project shows

This project demonstrates the core ideas behind MLOps without becoming too complex.

1. Reproducible training

All training happens inside a Docker container. This makes the process repeatable.

2. Experiment tracking and model versioning

MLflow stores metrics, parameters, artifacts, and model versions. Each training run creates a new version in the model registry.

3. Workflow orchestration

Airflow triggers the pipeline steps. For example:

  • generate synthetic data
  • Run model training
  • Update the model registry

4. Model lifecycle management

Training is only the first step. A model also needs:

  • logging
  • tracking
  • versioning
  • promotion to a production stage
  • regular monitoring

5. Model serving

The FastAPI service loads the Production model directly from MLflow. It does not retrain anything. It only serves predictions.

This shows a clean separation between training and serving.


Architecture overview

Article content
MLOPS


Model serving: single prediction and batch prediction

The API supports two kinds of prediction calls.

Single prediction

You send one transaction record. The API returns one fraud probability. This is similar to real-time scoring.

Batch prediction

You send a list of multiple records. The API returns a list of fraud probabilities. This is similar to daily or hourly batch processing jobs.

Both types use the same Production model, which keeps the behaviour consistent.


Technologies used

  • Python and scikit-learn for training
  • MLflow for tracking and model registry
  • Docker Compose for local setup
  • FastAPI for serving predictions
  • Airflow for orchestration
  • Pandas and NumPy for data handling
  • A synthetic data generator for consistent experiments

All components run locally so that anyone can try the system end-to-end.


This project shows how all parts of an ML system work together. It is meant for students, engineers, and anyone who wants to understand the basics of MLOps in a simple environment without cloud services.

You can find the complete code here: https://github.com/ankit-khare-2015/local-mlops-fraud-classifier

I have explored it however not in production

Like
Reply
Yuki Watanabe

Open Source / SWE at Databricks

4mo

Great work, Ankit! "Training is only the first step" is spot on. The end-to-end coverage (registry, promotion, serving) is what most tutorials skip. Curious have you explored applying this same thinking to LLM workflows with MLflow? Seems like a natural extension.

To view or add a comment, sign in

Others also viewed

Explore content categories