Altering the Suit While the Client Is Still Wearing It

Opening Scene

Adjusting a garment that’s hanging quietly on a rack is one kind of work — careful, unhurried, plenty of time to double-check every measurement. Adjusting a garment while the client is standing right there, mid-fitting, needing an answer in the next few minutes, is an entirely different kind of work. The same fundamental skill applies, but the pace, the tooling, and the tolerance for error are all completely different when the work has to happen live, under real time pressure.

That same distinction — careful, unhurried batch work versus fast, live, real-time work — is exactly the difference between computing features in scheduled batches and computing them in real time as data actually arrives.

In Plain English

Batch feature computation processes data on a schedule — nightly, hourly — with time to be careful and thorough. Real-time (or streaming) feature computation calculates features the moment new data arrives, fast enough to support an immediate decision, like flagging a transaction as it happens rather than reviewing it the next morning. The two approaches often need to produce consistent results from the same underlying logic, which is a harder engineering problem than it sounds — a mismatch here is exactly the kind of practical risk flagged back in Article 12’s discussion of time-based features.

The Old Way

Before real-time feature computation was widely practical, most feature work happened purely in batches:

A bank reviewing transactions for fraud the next business day, rather than at the moment of the transaction itself.
A retailer restocking shelves based on last week’s sales report, rather than adjusting live as items sold out.
A hospital reviewing patient vitals during scheduled rounds, rather than monitoring them continuously in real time.

In each case, batch processing was the practical default, and the cost of that delay — a fraudulent transaction going through, a shelf sitting empty, a vital sign going unnoticed — was simply accepted as an unavoidable tradeoff.

What’s Changing (and Why AI Is the Reason)

Streaming infrastructure has matured enough that real-time feature computation is now practical for many organizations, not just the largest, most resource-rich ones, closing a gap that used to require enormous specialized engineering investment.
AI-driven decisions increasingly need to happen at the moment of an event, not the next day, which raises the practical stakes of getting real-time feature computation right — a fraud model that only runs overnight is far less useful than one that runs the instant a transaction occurs.
Tooling increasingly helps ensure the same feature logic produces consistent results whether run in batch or real time, directly addressing the training-versus-production mismatch risk that used to be a common, hard-to-catch source of real-world model failure.

The Metaphor, Fully Extended

Tailor Shop	Real-Time Feature Concept
Careful, unhurried work on a garment hanging on the rack	Batch feature computation, done on a schedule
Live adjustments made while the client is still standing there	Real-time or streaming feature computation
The same underlying tailoring skill applied in both settings	The same feature logic intended to apply consistently in both
A live adjustment that doesn’t match what would’ve been done later	A real-time feature that inconsistently diverges from its batch version
A shop investing in the tools needed for confident live work	An organization investing in real-time feature infrastructure
A client who needs an answer in minutes, not overnight	A decision that genuinely needs to happen at the moment of the event

For Beginners: What to Actually Do

Understand which of your features genuinely need real-time computation versus which can reasonably wait for a scheduled batch — not every use case actually requires the added complexity of real time.
If working with real-time features, explicitly check that the logic matches the batch version used during training — this consistency is not automatic.
Recognize real-time feature computation as a genuinely harder engineering problem than batch, and budget accordingly.

For Practitioners and Leaders: The Deeper Layer

Only invest in real-time feature infrastructure where the decision genuinely needs to happen at the moment of the event — it’s a real cost, not a default best practice for every use case.
Building and testing for training-serving consistency between batch and real-time feature computation deserves its own explicit validation step, not an assumption that “the logic is the same, so the results will be too.”
A feature store, from Article 17, is often the practical infrastructure that makes serving consistent features across both batch and real-time contexts genuinely manageable.

Quick Recap

Batch feature computation happens on a schedule; real-time computation happens the moment new data arrives, supporting immediate decisions.
This mirrors the difference between careful, unhurried work off a rack and fast, live adjustments made under real time pressure.
Real-time feature infrastructure has become far more practical to build, closing a gap that used to require major specialized investment.
Ensuring consistent results between batch and real-time computation of the same feature is a genuine, non-trivial engineering challenge worth validating explicitly.

Where This Fits in the Series

Article 17 covered centralized feature infrastructure; this article covered the added challenge of computing features live, in real time. Article 19 looks at one of the most damaging mistakes possible in feature engineering — accidentally letting future information leak into training.