Inferensys

Glossary

Online Inference

Online inference is the process of generating machine learning model predictions in real-time against a single data point or transaction as it arrives, typically within a strict low-latency budget.
Data scientist building training data pipeline on laptop, data preprocessing visible, technical workspace.
REAL-TIME PREDICTION SERVING

What is Online Inference?

Online inference is the process of generating model predictions in real-time against a single data point or transaction as it arrives, typically within a strict low-latency budget.

Online inference is the computational process where a deployed machine learning model generates a prediction for a single, specific input—such as a credit card transaction—immediately upon request. Unlike batch inference, which processes large datasets asynchronously, online inference operates on the hot path of an application, demanding sub-second, often single-digit millisecond, response times to avoid blocking critical business flows like an authorization flow.

This architecture requires a dedicated serving infrastructure where the model is loaded into memory and exposed via a low-latency API, often a gRPC or REST endpoint. To prevent training-serving skew, the serving system must be tightly integrated with a feature store that provides pre-computed, real-time features—such as sliding window aggregations and velocity checks—at the moment of prediction, ensuring the model evaluates the transaction against the most current behavioral context.

REAL-TIME PREDICTION

Key Characteristics of Online Inference

Online inference is defined by its ability to serve a single prediction against one data point with strict latency guarantees. These characteristics distinguish it from offline batch processing and define the engineering constraints for fraud detection pipelines.

01

Single-Transaction Scoring

Online inference processes one transaction at a time as it arrives, rather than accumulating data into batches. Each request is stateless and independent, generating a risk score for that specific event. This contrasts with batch inference, which processes millions of records simultaneously. In a payment authorization flow, the model must evaluate a single ISO 8583 message and return a score before the authorization timeout expires.

02

Strict Latency Budget

Every online inference operation must complete within a predefined service-level objective (SLO) , typically measured in milliseconds. For financial fraud detection, the P99 latency is the critical metric—it defines the worst-case response time for 99% of requests. A typical budget might be 50-100ms for the entire scoring pipeline, including feature retrieval, model execution, and response serialization. Exceeding this budget risks transaction abandonment or timeout at the point of sale.

03

Real-Time Feature Assembly

Before a model can score a transaction, features must be assembled from multiple sources with zero perceptible delay. This involves:

  • Stream-table joins to enrich the event with merchant profiles or account history
  • Sliding window aggregations for velocity checks on card numbers or IP addresses
  • External service calls for device fingerprinting or geolocation All feature assembly must complete within a fraction of the total latency budget, often using a feature store to serve pre-computed aggregates.
04

High Availability Requirements

Online inference systems must maintain five-nines (99.999%) availability because downtime directly blocks revenue-generating transactions. This demands:

  • Circuit breaker patterns to fail gracefully when downstream services degrade
  • Redundant model replicas across availability zones
  • Shadow mode deployment to validate new models without risking production traffic A failed inference call in a payment flow typically results in a declined transaction, making resilience non-negotiable.
05

Deterministic Output Format

The inference response must be strictly structured and immediately actionable by the downstream authorization system. A typical response includes:

  • A numerical risk score (e.g., 0-1000)
  • A decision recommendation (approve, decline, step-up authentication)
  • Reason codes for explainability and regulatory compliance This structured output feeds directly into a rules engine or decision table that executes the final deterministic action based on the model's probabilistic assessment.
06

Idempotent Execution

Network retries in payment systems can cause duplicate inference requests for the same transaction. Online inference must be idempotent—processing the same request multiple times must yield the same result and produce no duplicate side effects. This is enforced through idempotency keys that uniquely identify each transaction. The system checks if a score has already been computed for a given key and returns the cached result rather than re-executing the model.

ONLINE INFERENCE

Frequently Asked Questions

Clear, technically precise answers to the most common questions about real-time model prediction in fraud detection pipelines.

Online inference is the process of generating a model prediction against a single data point or transaction synchronously as it arrives, typically within a strict low-latency budget of under 100 milliseconds. Unlike batch inference, which processes large datasets offline, online inference deploys a pre-trained model behind a high-availability API endpoint. When a transaction event enters the hot path, the system fetches pre-computed features from a low-latency feature store, constructs the feature vector, executes the model forward pass, and returns a risk score before the authorization flow times out. This architecture is critical for fraud detection because the decision to approve or decline must occur before funds are transferred, making the inference latency a hard constraint on the entire pipeline.

INFERENCE PARADIGM COMPARISON

Online Inference vs. Batch Inference

Architectural and operational comparison of real-time single-transaction prediction versus high-throughput offline processing for fraud detection workloads.

FeatureOnline InferenceBatch Inference

Latency Budget

< 50ms (P99)

Minutes to hours

Input Granularity

Single transaction/event

Millions of records

Trigger Mechanism

Event-driven (API call)

Schedule-driven (cron job)

State Management

Serving Infrastructure

REST/gRPC microservice

Spark/Flink/MapReduce

Use Case

Authorization flow scoring

End-of-day risk reporting

Feature Freshness

Real-time with sub-second staleness

T+1 or hours-old snapshots

Compute Pattern

Constant low-level utilization

Bursty high-throughput spikes

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.