Hot Path

The defining constraint of a hot path is a strict P99 latency target, typically under 50-100 milliseconds end-to-end. This budget must cover network transit, deserialization, feature lookups from a low-latency feature store, model inference, and the final decision response. Exceeding this budget results in timeouts that disrupt the authorization flow, forcing a fallback to a static rules engine and nullifying the value of the ML model.

Unlike batch training, the hot path cannot tolerate garbage collection pauses or resource contention. It relies on pre-allocated memory, just-in-time (JIT) compiled code, and non-blocking I/O. Techniques like object pooling and avoiding dynamic memory allocation are critical to ensuring that a P99 latency outlier does not cascade into a system failure, triggering the circuit breaker pattern.

The hot path must maintain local, in-memory state to compute velocity checks and sliding window aggregations without querying a remote disk. Technologies like Apache Kafka Streams or Apache Flink embed a RocksDB state store directly in the processing node. This allows for sub-millisecond lookups to answer questions like 'How many transactions has this device fingerprint seen in the last 5 minutes?' using a count-min sketch.

A hot path must never crash the transaction flow. If an external data enrichment service for geolocation times out, the path must proceed with a degraded score rather than blocking the payment. This is implemented via backpressure handling, strict timeouts on external calls, and the circuit breaker pattern. A dead letter queue (DLQ) captures malformed messages asynchronously so the main pipeline is not blocked by a single poison pill message.

Financial ledgers require absolute consistency. The hot path must guarantee exactly-once semantics to prevent a network retry from charging a customer twice or, conversely, failing to log a fraudulent attempt. This is achieved by passing an idempotency key from the client and coordinating transactional state between the stream processing engine and the sink, ensuring that a retried message updates the score but does not duplicate the side effect.

Before a new model enters the critical authorization path, it is deployed in shadow mode. The candidate model receives a mirrored copy of live traffic, logs its predictions, and compares them against the champion model's output—all without affecting the actual authorization decision. This allows engineers to validate online inference performance and detect model drift in a zero-risk environment before a full cutover.

The core function of the hot path: calculating a fraud probability score before the authorization response is sent. This involves executing the online inference model against the enriched transaction event within a 50-100ms budget.

• Feature vector assembly: Joining the transaction with real-time velocity checks and device fingerprints
• Model execution: Running gradient-boosted trees or neural networks optimized for CPU-bound inference
• Threshold evaluation: Comparing the score against risk-based decision tables to produce an approve, decline, or step-up action

Detecting anomalous bursts of activity by computing sliding window aggregations over streaming transaction attributes. A sudden spike in transactions from a single IP address or card BIN within a 5-minute window is a classic indicator of a carding attack.

• Count-Min Sketch: Probabilistic data structure for approximate frequency counting with sub-linear memory
• Token Bucket Algorithm: Rate-limiting pattern that allows bursts while enforcing a sustained throughput cap
• Window types: Tumbling windows for fixed intervals, hopping windows for overlapping periods, and session windows for user activity

Checking the transacting entity against sanctions lists, politically exposed persons databases, and internal blocklists in real time. This must complete before authorization to prevent funds from reaching restricted parties.

• Bloom Filter: Space-efficient probabilistic structure for rapid membership testing with zero false negatives
• Exact matching: Deterministic lookup against hashed identifiers using in-memory key-value stores
• Fuzzy matching: Levenshtein distance and phonetic algorithms for name screening against OFAC and UN sanctions lists

Generating and evaluating a unique identifier from the transacting device's attributes to detect account takeover and bot activity. The fingerprint must be computed and compared against known-good profiles within the hot path window.

• Passive signals: Browser canvas hash, WebGL renderer, installed fonts, and TLS fingerprinting
• Reputation scoring: Checking the fingerprint against a database of known fraudulent devices
• Velocity correlation: Linking multiple accounts to a single device fingerprint to detect fraud rings

The hot path operates within the ISO 8583 authorization flow, the standardized messaging protocol between acquirers and issuers. The fraud system must intercept, enrich, score, and return a decision without breaking the strict timeout constraints of the payment network.

• Circuit Breaker Pattern: Gracefully degrading to a rules-only decision if the ML model service becomes unavailable
• Idempotency Key: Preventing duplicate charges by ensuring retried authorization requests are processed exactly once
• Shadow Mode Deployment: Running a new model in parallel with production to validate performance without impacting live decisions

When a transaction event cannot be processed successfully in the hot path—due to malformed data, schema violations, or enrichment service timeouts—it must be routed to a Dead Letter Queue for offline inspection without blocking the main pipeline.

• Backpressure handling: Applying flow control when downstream enrichment services slow down
• Schema validation: Using a Schema Registry to enforce Avro or Protobuf message contracts before processing
• Watermark tracking: Declaring a threshold timestamp after which late-arriving events are routed to cold storage rather than the hot path