Powering Models: Feature Engineering, Part 2

Wed, 13 May 2026 10:00:00 -0600

Part 1 covered the offline side: getting features built, validated, and automated. This post picks up at the point where a model is deployed and a service needs to call it.

The question is deceptively simple: how does the model get the features it needs when a request comes in?

There are two answers, and most real systems use both depending on the feature type.

The two patterns

 flowchart LR
 classDef caller fill:#eff6ff,stroke:#3b82f6,stroke-width:1.5px,color:#1e3a5f
 classDef svc fill:#f5f3ff,stroke:#8b5cf6,stroke-width:1.5px,color:#3b0764
 classDef model fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
 classDef store fill:#fefce8,stroke:#eab308,stroke-width:2px,color:#713f12

 subgraph patternA[" Pattern A · Features in the request "]
 C1[Client / Caller]:::caller -->|"payload includes features"| SVC1[Prediction Service]:::svc
 SVC1 --> M1[Model]:::model
 M1 -->|prediction| C1
 end

 subgraph patternB[" Pattern B · Features from online store "]
 C2[Client / Caller]:::caller -->|"entity ID only"| SVC2[Prediction Service]:::svc
 SVC2 -->|"fetch features"| FS[("Online Feature Store")]:::store
 FS -->|"feature vector"| SVC2
 SVC2 --> M2[Model]:::model
 M2 -->|prediction| C2
 end

Pattern A puts the burden on the caller. The upstream service computes or collects the features and sends them as part of the request payload.

Serving on Varchaleswari Ganugapati

Powering Models: Feature Engineering, Part 2

The two patterns