ONLINE ML · PRODUCTION ARCHITECTURE · CONTINUOUS EVIDENCE

“Online” does not mean only one thing.

Some systems predict instantly but train in batches; some refresh features continuously; only a smaller class updates model parameters event by event.

01 · PREDICTmilliseconds
02 · FEATUREseconds–minutes
03 · LEARNevent-by-event
04 · VERIFYlabels arrive later

THREE PRODUCTION PATTERNS

Name exactly what is online.

All three may coexist, but they carry different state, latency, failure modes and evaluation protocols.

01

Online Inference

The model is temporarily fixed; predictions are immediate.

The most common production meaning—even though no learning occurs per request.
Request
Online features
Model server
Prediction + log

What must be fast

Feature lookup, preprocessing parity, model execution and response serialization.

Typical stack

Feast/Redis · KServe/Triton/BentoML · XGBoost/ONNX/PyTorch.

Examples

Fraud, product ranking, credit scoring and image inference.

request → online_features(entity_id, event_time) → model.predict(feature_vector) → log(prediction_id, feature_version, model_version)
02

Online Feature Computation

Features evolve continuously; training may remain batch-oriented.

This powers much fraud and recommendation. Freshness often comes from features, not new weights.
Kafka / events
Flink / SQL / IVM
Feature state
Inference

Maintained state

Count, sum, mean, variance, distinct entities, recency, histogram and co-occurrence.

Time semantics

Event time, processing time, late events, watermarks, sliding windows and expiration.

Examples

5-minute velocity, 7-day spend and 24-hour CTR.

new_event(entity=104, amount=2500) → count_5m += 1 → sum_7d += 2500 → expire old contributions → serve revised features
03

True Online Learning

Predict first; update model state when its label arrives.

Use when the environment changes rapidly, feedback is trustworthy and update risk is controlled.
xₜ
predict_one
delayed yₜ
learn_one + checkpoint

Suitable models

Online linear/logistic models, Naive Bayes, Hoeffding trees, bandits and incremental anomaly detection.

Typical tools

River · Vowpal Wabbit · sufficient-statistic updates.

Risks

Poisoning, feedback loops, catastrophic forgetting, label delay and rollback.

ŷₜ = predict_one(xₜ) → log evidence → wait for verified yₜ → metric.update(yₜ, ŷₜ) → learn_one(xₜ, yₜ) → checkpoint

DECISION TABLE

Choose from latency and change.

Per-event model updates are not automatically more mature. Many systems should stop at Pattern 1 or 2.

QuestionOnline inferenceOnline featuresTrue online learning
Immediate changePredictionFeature stateModel parameters
Immediate label?NoNoNo, but it must be joinable later
Best whenResponse must be fastRecent behaviour mattersConcept changes rapidly
EvidenceLatency, availabilityFreshness, skew, driftProgressive loss, regret, stability
RollbackModel versionFeature state/versionCheckpoint + replay log

SCENARIOS

Different products need different kinds of online.

Select a case to inspect prediction latency, feature freshness and label delay.

Payment Fraud

Inference precedes authorization; velocity must be fresh, while chargeback truth may arrive days later.

<100 msinference
1–10 sfeatures
dayslabel delay

Recommendation

Popularity and session context move quickly; large embeddings refresh periodically and bandits handle exploration.

<50 msranking
secondssession
minutes+feedback

Predictive Maintenance

Sensor features stream continuously, but rare failure labels favour drift-gated micro-batch retraining.

secondswindows
rarelabels
scheduledretraining

DRIFT & DELAYED TRUTH

Prediction happens now; truth may arrive next week.

Preserve prediction identity, event time, feature version and model version so delayed truth reconnects to evidence.

Separate the signals

Feature drift: P(X) · Label drift: P(Y) · Concept drift: P(Y|X) · Prediction drift: P(Ŷ) · Performance drift: loss after labels arrive.

prediction_log(prediction_id, entity_id, event_time, feature_version, model_version, predicted_label, probability)
verified_labels(prediction_id, label_time, actual_label)
evaluate by prediction event window—not only label arrival time

PRACTICAL WARIN.ME STACK

Small enough to learn; real enough to expose production boundaries.

Use ClickHouse as the evidence/state engine, adding River or Vowpal Wabbit only for true online updates.

Events
ClickHouse state
Inference API
Drift + labels
River/VW or retrain