Real-time Feature Computation
Batch features update once a night. But if a user clicks a product 5 seconds ago, the recommendation model needs to know *right now*. Real-time feature computation uses streaming architectures to calculate features instantly as events happen.
Why Does This Exist?
Most machine learning features are Batch Features. They are calculated using a heavy SQL query that runs once a night. A feature like user_account_age_days doesn't need to be updated by the millisecond.
However, for specific domains like Fraud Detection or TikTok-style Recommendations, milliseconds matter.
If a user just added a \5,000$ TV to their cart, you cannot wait for tonight's batch job to update their cart_value feature. If you do, the live fraud model won't see the massive spike in cart value and will approve the fraudulent transaction.
Real-time Feature Computation allows systems to listen to live events (clicks, swipes, purchases) and calculate aggregations (like "Number of swipes in the last 10 seconds") instantly, so the ML model has access to ultra-fresh context.
Think of It Like This
Think of It Like This
Imagine a basketball coach trying to decide who to substitute into the game.
A Batch Feature is looking at a player's season average from yesterday's newspaper. A Real-time Feature is the assistant coach standing next to the bench with a stopwatch, counting exactly how many times the player sprinted in the last 60 seconds, and shouting it to the head coach right now.
How It Actually Works
Calculating features in real-time is an intense distributed systems problem. You cannot run a SQL GROUP BY query on a live database 1,000 times a second; it would melt the server. Instead, we use Stream Processing.
1. The Event Bus (Kafka / Kinesis)
Every action a user takes on the app is immediately published as a JSON message to an Event Bus. The bus acts as an incredibly fast, highly-available conveyor belt for data.
2. The Streaming Engine (Flink / Spark Streaming)
A stream processing engine subscribes to the Event Bus. Instead of storing data on disk and querying it later, it processes the data in-memory as it flies by.
If we need to calculate clicks_last_60_seconds, the streaming engine maintains a "Sliding Window" in RAM. Every time a new click arrives, it adds 1 to the counter. Every time a click gets older than 60 seconds, it subtracts 1.
3. Pushing to the Online Store
The moment the counter changes, the streaming engine immediately pushes the new value (e.g., clicks = 14) directly into the Online Feature Store (like Redis).
A few milliseconds later, when the ML API asks Redis for the user's features, it receives the ultra-fresh value.
Show Me the Code
Writing streaming logic in Java/Scala using Apache Flink is complex. However, modern abstractions (like Flink SQL or tools like Bytewax) allow you to define streaming aggregations using standard syntax.
Here is a conceptual example of defining a sliding window feature using Streaming SQL.
-- 1. We define the incoming stream of raw events from KafkaCREATE TABLE click_stream ( user_id BIGINT, click_time TIMESTAMP(3), WATERMARK FOR click_time AS click_time - INTERVAL '5' SECOND) WITH ( 'connector' = 'kafka', 'topic' = 'live_clicks');
-- 2. We define the logic to calculate the feature on the fly.-- We use a HOPPING window: it looks at the last 60 seconds of data, -- but it updates the calculation every 5 seconds.INSERT INTO redis_online_storeSELECT user_id, COUNT(*) as clicks_last_60sFROM click_streamGROUP BY user_id, HOP(click_time, INTERVAL '5' SECOND, INTERVAL '60' SECOND);Watch Out For
Watch Out For
Late Events and Watermarks. In the real world, mobile phones lose cell service. A user might click a button at 12:00:00, but their phone doesn't regain signal to send the event to your server until 12:00:15. If your streaming engine relies purely on "server time", the event will be counted in the wrong window. Streaming engines use "Watermarks" to allow a grace period for late-arriving events based on the event time stamped by the phone, before finally closing the calculation window.
The Quick Version
- Batch features are calculated slowly, overnight, on data warehouses.
- Real-time features are calculated instantly, in-memory, using stream processing.
- The architecture requires an Event Bus (like Kafka) to catch raw user actions.
- A Streaming Engine (like Apache Flink) listens to the bus, calculates aggregations using Sliding Windows, and pushes the result directly to an Online Feature Store (like Redis).
- This is essential for latency-sensitive models like Fraud Detection and live Recommendations.
What to Read Next
feature-stores— How the Online Store stores these real-time features and serves them to the ML model.online-evaluation— How you can use streaming engines not just to calculate features, but to calculate the real-time accuracy of your deployed model.