iFood: real-time feature platform for anti-fraud (250 → 50 ms)

01 · CONTEXT AND PROBLEM

Real-time fraud demands fresh features

Fraud prevention is crucial in the Food Tech ecosystem, and iFood has become an attractive target for fraudsters, especially those who test stolen or generated cards. In response, iFood combines traditional security mechanisms with advanced artificial intelligence models that assess, among many parameters, the risk of future chargebacks.

Managing these models is complex: one of the challenges is keeping features up to date and ensuring integrity and low latency in data access. The answer was a Feature Platform, in which data scientists define the what and the platform manages the how.

02 · THE PLATFORM

Three layers and an end-to-end flow

The platform is made up of three main abstractions: the Feature Engine, the Feature Store, and the Feature Management. The Engine computes the feature, the Store stores and serves the features consistently, and the Management ensures the platform's integrity, efficiency, and security.

The integrated tools include Apache Spark, Apache Kafka, Delta Lake, and Redis, and the platform was built mainly to process features in real time, with streaming as its main focus. One stated advantage is reuse: existing features can be shared across different models, without recreating or reprocessing features for each new model.

The Feature Management includes continuous monitoring, feature lifecycle management (which can be deleted, which are accessed and by whom, plus cost), and versioning, which keeps the history of all changes.

1. In the diagram, the event stream is the input to the Feature Engine.

2. Each feature update is stored in a Delta Table located in an S3 bucket.

3. The materializers read the transactions from the Delta Table and store them in the appropriate destination.

4. The Redis Materializer saves only the most recent version of the feature in Redis.

5. The Delta Materializer ensures history consistency, storing it in a Delta Table.

6. For real-time features there is a REST API, which serves models on SageMaker and other applications.

03 · FEATURE ENGINE

Two-step aggregation

Data scientists often create several similar features that vary only in the window, such as the count of orders over the last 7, 30, and 60 days. That is why iFood developed what it calls two-step aggregation.

The Two Step Aggregator organizes the data into smaller windows, called steps; if the goal is to aggregate a month, the step can be one day. The results of these small segments are stored as intermediate states and then combined to produce the final aggregation.

Among the benefits cited is cost reduction, because several windows are processed in a single Spark query execution, and the same codebase processes both batch and streaming.

Each feature update becomes a new entry in the Delta Table, which makes it easier to rebuild any database at later points in time, analogous to a transaction log.

1. In the diagram, the input data reaches the step aggregation.

2. The data is organized into smaller windows, the steps; for a month, the step can be one day.

3. The results of these small segments are stored as intermediate states.

4. The intermediate states are combined to produce the final aggregation, and several windows come out of a single Spark query execution.

5. Each feature update is stored in a Delta Table.

04 · FEATURE STORE

Online to serve, offline to train

The Feature Store is the repository of processed features ready for use in machine learning models, segmented into two categories. The table summarizes what the text says about each one.

In online storage, iFood keeps the features in Redis and reaches latencies below 10 milliseconds; combined with an application on Kubernetes, it reaches rates of 3 million requests per minute, and in low-traffic moments unneeded resources are shifted away.

Offline storage makes it possible to retrieve a feature's value at a certain point in time, which is required for model training, and each store also has its own specific consumer.

05 · TRAINING AND INFERENCE

Two ways to read the same feature

In training, data accuracy is the main concern, with no need to focus on latency. Extraction uses a unique identifier and a precise point in time, with a closed time window: the chosen moment must always be after the end of the window, to ensure future information is not exposed.

The final product is a Spark dataframe in which each characteristic becomes a distinct column.

In inference, latency plays a crucial role and the identifier alone is enough to access the most recent data. iFood offers a specialized, highly scalable REST API capable of processing millions of requests per minute, and each model retrieves through it all the features needed for its inference step.

According to iFood, the platform tackled the problem of differences between the feature logic in the training pipeline and the logic for inference, the feature skew.

1. In the diagram, there are two read paths: one starts from the training SDK and the other from the fraud model.

2. For history there is a Python SDK that fetches the historical data.

3. The query uses an identifier and a point in time, which must be after the end of the window.

4. Each model accesses the feature platform through the API, retrieving the features it needs.

5. In inference, the identifier alone is enough to access the most recent data, stored in Redis.

06 · RESULT AND LIMITS

What changed and what the text does not show

According to iFood, the fraud system's average response time was 250 ms before the platform and dropped to 50 ms after it. The text also describes the latency reduction in feature retrieval from 250 ms to 50 ms, roughly five times.

The fraud models already used Amazon SageMaker, but iFood faced internal challenges related to creating and maintaining features.

By treating features as code and offering a standardized library, iFood encouraged feature reuse and discovery across teams. According to the text, the platform serves more than a billion requests a day, spans more than 800 features, and is used by teams such as recommendation, logistics, and marketing.