From ML Model to Production-Ready Service
How I transformed a churn prediction model into a usable service
1Transition to Data Engineering
To shift from data analytics to data engineering, I built two real-world projects: a GitHub ETL pipeline loading repos into SQLite, and an RSS pipeline storing articles in Kestra DB. These ran as automated hourly jobs via GitHub Actions and Kestra orchestration, giving me hands-on data engineering experience.
2Churn Prediction Model
I developed a churn prediction model for fictional telecom Northline Mobile using data from 7,043 customers. The model achieved 81% accuracy by analyzing contract types, tenure, monthly charges, and add-ons. I validated it with unseen customer data through cross-validation, learning the end-to-end model building process.
3Model Limitations
While the model worked in Jupyter notebooks, it wasn't production-ready. Northline employees would need to manually run notebook cells in order to get predictions. This made the model impractical for real business use, highlighting the gap between experimentation and deployment.
4Model as a Service
There's a crucial difference between having a model in a notebook and having a deployable service. By wrapping the model with FastAPI, I created a web service that other teams and applications could consume without knowing ML details, enabling integration with Northline's systems.
5API Design Choices
I faced two API design approaches: simplified inputs vs full-fidelity processing of all original dataset fields. I chose full-fidelity to handle raw customer data identical to training data. The API transforms incoming JSON into the model's expected format, maintaining consistency with preprocessing steps.
6Sample API Request/Response
A typical request includes customer demographics, service details, and payment info. The response provides simple, actionable outputs: churn probability (0.3136), binary prediction (0/1), and risk level (Low/Medium/High) with thresholds at 0.3 and 0.6. These buckets make probabilities immediately interpretable.
7Preprocessing Consistency
Identical preprocessing during training and inference is critical. If training scaled tenure and MonthlyCharges certain way, the API must replicate this exactly. Inconsistent preprocessing would degrade model performance, making production monitoring essential for data drift detection.
8FastAPI's Role
FastAPI served as the deployment tool, but the key challenge was designing the boundary between software and model. Architectural decisions about input validation, error handling, and output formatting mattered more than the specific web framework used to expose the service.
9Production Challenges
Moving from notebook to production introduces scalability, security, versioning, and monitoring requirements. While this project created a basic service, real production would need CI/CD pipelines, logging, metrics, and potentially a model registry for proper ML operations.
10UX Improvements
Raw probabilities (like 0.31) aren't actionable for business users. I added simple risk buckets (Low/Medium/High) with initial thresholds at 0.3 and 0.6. These provide immediate insight while acknowledging they're starting points that could be refined through statistical analysis or business input.
11Next Steps
Future improvements include enhancing model performance with more data, adding API features like batch predictions, and implementing production essentials: real-time monitoring, automated retraining, and proper model versioning to support iterative improvements without service disruption.
12Key Takeaways
This project showed that building an ML model is just the beginning. Making it truly useful requires packaging as a service with clean interfaces that meet user needs. The process demands both technical skills and product thinking to bridge the gap between experimentation and production impact.
Original article: Towards Data Science — Makine Öğrenimi Modelinden Kullanılabilir Servise Dönüşüm