Backpressure Handling

The foundational asynchronous, non-blocking standard for handling backpressure in JVM-based systems. It defines a clear contract between Publisher and Subscriber interfaces.

• request(n): The subscriber signals exactly how many elements it can process
• onNext: The publisher pushes only the requested number of items
• onComplete/onError: Terminal signals that end the stream

This pull-based model prevents the consumer's buffer from being flooded, ensuring memory stability even when processing millions of transactions per second.

When a downstream consumer cannot keep pace, buffering provides temporary storage to absorb the burst. Different strategies offer distinct trade-offs for fraud detection pipelines.

• Fixed-Size Buffer: Drops the oldest or newest elements when full, preventing memory exhaustion
• Unbounded Buffer: Stores all overflow but risks OutOfMemoryError under sustained pressure
• Ring Buffer: A lock-free, pre-allocated circular data structure used in high-performance disruptor patterns

In payment systems, bounded buffers with a drop-oldest policy are preferred to prioritize fresh transactions over stale ones.

Backpressure is not limited to application code; it propagates down the network stack. When a consumer's socket receive buffer fills up, TCP's flow control mechanism kicks in.

• The receiver advertises a shrinking TCP window size
• The sender's TCP stack halts transmission until the window opens
• This backpressure cascades upstream through load balancers and API gateways

This natural throttling protects fraud scoring services from being overwhelmed at the network level, but requires careful tuning of SO_RCVBUF kernel parameters to avoid head-of-line blocking.

In Apache Kafka-based fraud pipelines, consumer lag serves as a critical backpressure indicator. Lag measures the delta between the latest produced offset and the last committed consumer offset.

• Lag > Threshold: Triggers autoscaling of consumer instances or alerts operations teams
• Pause/Resume: Consumers can programmatically pause partition fetching when processing slows
• Max.poll.records: Limits the number of records fetched in a single poll loop

Monitoring lag via tools like Burrow or Confluent Control Center provides a direct window into pipeline health and backpressure accumulation.

When backpressure mechanisms are insufficient to handle extreme load, deliberate degradation strategies are required to preserve core system functionality.

• Load Shedding: Intentionally dropping a percentage of incoming requests at the edge before they consume resources. Non-critical transactions are rejected with a 503 Service Unavailable
• Throttling: Rate-limiting specific clients or transaction types using algorithms like the Token Bucket or Leaky Bucket

For payment authorization flows, load shedding is applied to low-risk, low-value transactions first, ensuring high-value and high-risk transactions always receive full scoring.

In distributed fraud scoring systems, asynchronous microservices communicate via message queues. Acknowledgment-based flow control ensures no message is lost while preventing consumer overload.

• Manual Ack: The consumer explicitly acknowledges each message after successful processing
• Prefetch Count: Limits the number of unacknowledged messages a consumer can hold (e.g., RabbitMQ's QoS prefetch)
• Negative Acknowledgment (NACK): Rejects a malformed message, routing it to a Dead Letter Queue

Setting a low prefetch count (e.g., 1) maximizes fairness across consumers but reduces throughput; higher values improve throughput at the cost of potential imbalance.

A specialized message queue for events that cannot be processed successfully after all retries are exhausted. Instead of blocking the main pipeline with poison pill messages, the DLQ isolates them for manual inspection.

• Prevents a single malformed transaction from creating backpressure on the entire stream.
• Enables offline forensic analysis of failed events.
• Critical for maintaining exactly-once semantics in the happy path while ensuring no data is silently dropped.

In fraud detection, a DLQ might hold transactions with corrupted ISO 8583 payloads.

A deliberate strategy of dropping a percentage of incoming requests when the system approaches overload. Rather than accepting all traffic and failing slowly, load shedding preserves latency for the requests it does accept.

• Prioritizes critical traffic over non-essential requests.
• Often implemented at the API gateway or load balancer.
• Uses queue depth or CPU utilization as the trigger signal.

For a fraud pipeline, this might mean dropping low-value transaction scoring requests during a spike to ensure high-value wire transfers are still evaluated.

Kafka's pull-based consumption model provides implicit backpressure. Consumers poll for messages at their own pace; if a consumer is slow, messages simply accumulate in the broker's partition.

• Consumer Lag: The metric tracking how far behind a consumer is from the head of the partition.
• Max Poll Records: A configuration to limit the batch size a consumer fetches.
• Pause/Resume: Consumers can programmatically pause a partition to stop fetching entirely.

Monitoring consumer lag is the primary observability signal for detecting backpressure in a Kafka-based fraud scoring pipeline.