From Model to Data Product: FastAPI & Docker

A model in a notebook answers questions only for the person running the notebook. A data product answers them for other systems, reliably: an HTTP endpoint that accepts a JSON request, validates it, returns a prediction in milliseconds, logs what happened, and behaves the same tomorrow as today.

The pieces from Lab 9 Part 2 / Assignment 04:

• models/model.joblib — the serialised model (or pipeline).
• models/model_metadata.json — model_version, feature_columns, training date, metrics. The API reports the version so every prediction can be traced to a model.
• src/common/features.py — the one place features are computed.
• src/api/main.py — FastAPI app with a Pydantic request schema and a /predict endpoint.
• A Dockerfile with pinned requirements.txt, so the runtime is identical everywhere.

Loading a model from disk takes time — tens to hundreds of milliseconds for a medium RandomForest. Predicting one row takes a few milliseconds. If /predict calls joblib.load() every time, almost all of every request is spent re-reading the same file.

Load it once when the app starts (module import or FastAPI lifespan) and keep it in memory:

@asynccontextmanager
async def lifespan(app):
    app.state.model = joblib.load("models/model.joblib")
    yield

Total time for N requests: per-request loading = N × (load + infer); startup loading = load + N × infer. With load = 150 ms, infer = 5 ms and 200 requests, that's 31 s vs 1.15 s.

Training-serving skew is when the features the model sees in production are computed differently from the features it was trained on. Nothing crashes — the API returns HTTP 200 with a perfectly valid number — but the number is wrong.

In Lab 9.2 Step 8, training defined is_rainy = rainfall_mm > 5.0, but a copy of the logic in the API used > 10.0. For rainfall_mm = 8.2, training says rainy, the API says not rainy, and the beans prediction silently moves from 2,927.25 to 2,889.58 UGX.

The fix is architectural, not "be more careful": put make_features() and FEATURE_COLUMNS in one shared module imported by both train.py and the API, save the feature list in the model metadata, and check at startup that the request schema produces exactly those columns in that order.

A Pydantic model turns the API's input contract into code:

class PriceRequest(BaseModel):
    market: Literal["Owino", "Nakasero", "Kalerwe", "Gulu"]
    commodity: Literal["Beans", "Maize", "Matooke", "Rice"]
    rainfall_mm: float = Field(ge=0, le=500)
    date: datetime.date

A bad payload — a negative rainfall, an unknown market, a missing field — gets an automatic HTTP 422 with a message saying exactly which field is wrong, before any model code runs.

Docker then freezes everything else: the Python version, the exact library versions (scikit-learn==1.5.2, not "whatever pip installs today" — a pickled model can break across versions), the code and the model file. Ordering the Dockerfile as copy requirements → pip install → copy code lets Docker cache the dependency layer, so a code change rebuilds in seconds.