Real-time serving

By defining features on top of operational data sources (Redis, JDBC, REST APIs), FeatureMesh serves features as production APIs with millisecond latency. The same feature definitions used for batch analytics work here, so what you trained on is what you serve.

How it works

Register the real-time sources you need:

CREATE FEATURE REDIS_SRC AS SOURCE_REDIS('redis://localhost:6379' WITH (timeout='100ms'));
CREATE FEATURE POSTGRES_SRC AS SOURCE_JDBC('postgresql://db:5432/prod' WITH (tables=ARRAY['customers']));
CREATE FEATURE API_SRC AS SOURCE_HTTP('https://api.risk.com' WITH (timeout='200ms'));

CREATE FEATURES AS
    CUSTOMERS := ENTITY(),
    CUSTOMER_ID := INPUT(BIGINT#CUSTOMERS),

    -- Profile tier from Redis
    PROFILE_TIER := EXTERNAL_REDIS(KEY 'customer:' || CUSTOMER_ID::VARCHAR FIELD 'tier' FROM REDIS_SRC),

    -- Customer balance from PostgreSQL
    CUSTOMER_DATA := EXTERNAL_COLUMNS(
      customer_id BIGINT BIND TO CUSTOMER_ID,
      balance DECIMAL
      FROM VIEW(POSTGRES_SRC[customers])
    ),
    BALANCE := CUSTOMER_DATA[balance],

    -- Credit score from a microservice
    CREDIT_SCORE_JSON := EXTERNAL_HTTP(FROM API_SRC WITH (query_params=ROW(CUSTOMER_ID AS id))),
    CREDIT_SCORE := JSON_PARSE_AS(CREDIT_SCORE_JSON, TYPE 'ROW(score INT)')[score]
;
sql

Define derived features on top:

CREATE FEATURES AS
    ELIGIBLE_FOR_LOAN := (CREDIT_SCORE > 650 AND BALANCE > 1000) OR PROFILE_TIER = 'VIP'
;
sql

Create a prepared statement for low latency serving:

CREATE FEATURE ELIGIBLE_FOR_LOAN_PS AS
PREPARED_STATEMENT(
    ELIGIBLE_FOR_LOAN
    USING INPUT CUSTOMER_ID
);
sql

Query it from anywhere:

curl -X POST "http://localhost:10090/v1/featureql" \
  -H "Content-Type: application/json" \
  -d '{
    "statement": {
      "id": "ELIGIBLE_FOR_LOAN_PS",
      "inputs": {"customer_id": [12345]}
    }
  }'
bash

A single request fetches data from Redis, PostgreSQL, and an HTTP API, evaluates the feature graph, and returns the result. The engine handles parallelization, connection pooling, and caching.

Why not a microservice?

The typical alternative is a custom microservice: a team writes the eligibility logic in Python or Java, deploys it behind an API, and maintains it. The logic is invisible to anyone who doesn't read that codebase.

With FeatureMesh, the logic is in the registry. ELIGIBLE_FOR_LOAN is queryable, auditable, and reusable. The lending API, the mobile app, the fraud system, and the analytics dashboard all use the same definition. When the rule changes, you update one feature, not four implementations.

This also means no deployment cycles for logic changes. Updating a feature definition changes production behavior immediately. Combined with VARIANT() and GRADUAL_ROLLOUT(), you can test changes on a fraction of traffic before committing.

Suggest changes to this page
Last update at: 2026/03/18 16:18:57
Last updated: 2026-03-18 16:19:34