A few months ago, I tried to challenge myself to undertake a journey to transition from a data analytics background to data engineering. So far I’ve built a total of two impactful real-world projects that actually taught me something useful. I built a Git Hub ET L pipeline that extracts Git Hub repositories and loads them into a SQLite database — this ran on a schedule using Git Hub Actions.

I also built an RSS pipeline that extracts articles from RSS feeds and stores them into a Kestra database — orchestrated by Kestra to run on an hourly schedule. Now that I’ve understood ET L to a point, I wanted to try something new. I wanted to keep practicing all I’ve learned in the past whilst building something new.

I had always been fascinated by the field of machine learning, but never actually had the courage to step in because I thought it had complex math. Not anymore. Recently, I built a churn prediction model for a fictional telecom company I am calling Northline Mobile (P.

S. I’m using a fictional company because I understand things best with real-world scenarios). I provided it with data from 7043 customers, telling it whether they had signed up for a 1-year contract or month-to-month plans, length of customer, monthly charges, add-ons, etc. Furthermore, I told it who eventually left Northline Mobile.

I cross-validated the model with customers it had not seen yet. It achieved 81% accuracy. This taught me everything that goes into building a model.

Obviously I didn’t understand all the complex code, because I prefer intuitive drag and drop interfaces rather than complex code. But I understood the essential building blocks of building a model; I’ll explain further below with a simplified architecture. So building this model felt like a win from a machine learning perspective; my model worked.

But there was still one problem: it was still not really useful. Assuming a Northline employee who needed a prediction comes to me, I would have to open Jupyter, load the right notebook, run the cells in the correct order and make a manual call to predict_churn(). Yeah, the model exists, but I was the only one that knows how to use it.

No one else at Northline could just send information on a customer to the model and retrieve a prediction and it could not speak to any other application either. This article will be covering this. I recently learned that there is a difference between having a model and having a service.

If a model just sits in a notebook only the person who built it can use it. But making it a service makes it possible for everyone to use it, other teams, apps, dashboards and systems that do not need to know or care how the prediction is made. It turns out building the machine learning model was the easiest part, but making it useful is another crucial element worth exploring.

What "Done" Meant Before the APIHere's roughly what building the model looked like: That’s pretty much it. Nothing too fancy. By the end of that, I had a trained churn classifier, a preprocessing pipeline that cleaned and encoded the raw data, and evaluation numbers I was comfortable with (more on those numbers shortly, they're not perfect and I'm not going to pretend they are).

But like I said. Assuming Northline's retention team builds a dashboard, and they want it to flag at-risk customers automatically. Their dashboard can't reasonably open my Jupyter notebook and run my cells.

It needs something else entirely. Something like this: That's the shift this article covers. One quick disclaimer, though: this isn’t a Fast API tutorial.

Fast API is simply the tool I happened to use to expose the model as ...