Backpressure

Backpressure arises when a producer generates data faster than a consumer can process it. Without intervention, this leads to buffer bloat, memory exhaustion, and eventual out-of-memory (OOM) crashes. The mechanism dynamically aligns throughput rates across the pipeline.

• Symptom: Rising consumer lag and increasing heap usage
• Root cause: Downstream bottlenecks like slow I/O, complex aggregations, or external API calls
• Example: A Kafka producer writing 100k msg/sec while a Flink consumer processes only 50k msg/sec

Backpressure in distributed systems mirrors TCP flow control. A TCP receiver advertises its receive window (rwnd) — the buffer space available — to the sender. The sender must not send more unacknowledged data than this window allows.

• rwnd shrinks: Consumer is saturated; sender slows down
• rwnd expands: Consumer catches up; sender resumes full speed
• Key difference: Application-level backpressure operates on logical records, not raw bytes

When backpressure is signaled, systems choose between two primary strategies:

• Buffering: Temporarily store excess data in memory or disk. Risk: unbounded growth leading to OOM if the consumer never recovers
• Dropping: Discard the oldest or newest messages. Used in sampling-based or loss-tolerant use cases like metrics
• Hybrid: Spill to disk when memory thresholds are breached, then read back when pressure eases

Kafka implements backpressure implicitly through consumer poll loop behavior. Consumers call poll() and process fetched records; if processing is slow, the next poll() is delayed, reducing fetch frequency.

• max.poll.records: Limits records fetched per poll to prevent overwhelming the consumer
• pause()/resume(): Explicit API to halt consumption on specific partitions
• Consumer lag: A metric tracking the delta between the latest offset and the consumer's committed offset, serving as a backpressure indicator

The foundational standard that defines backpressure semantics for asynchronous stream processing on the JVM. It specifies how a Subscriber signals demand to a Publisher using request(n) calls, preventing buffer bloat.

• Key Interfaces: Publisher, Subscriber, Subscription, Processor
• Goal: Provide a non-blocking protocol for flow control
• Implementations: Akka Streams, Project Reactor, RxJava

The metric that quantifies the delta between the latest produced message offset and the latest consumed offset in a partitioned log. High consumer lag is the primary symptom of a backpressure condition.

• Formula: Producer Offset - Consumer Offset
• Monitoring: Critical for triggering auto-scaling events
• Thresholds: Lag > 10,000 often indicates a bottleneck

TCP's receive window provides transport-level flow control, but it is insufficient for application health. If a consumer's application thread is blocked, TCP buffers fill and packets are dropped. Application-level backpressure propagates the signal up the logical pipeline.

• TCP: Prevents network buffer overflow
• App-Level: Prevents out-of-memory errors in the JVM/process
• Mechanism: Translates network pressure into logical throttling

A defensive strategy that intentionally drops a percentage of incoming requests when the system is saturated, rather than accepting them and failing slowly. This is an alternative to backpressure when the producer cannot be slowed down.

• Strategy: Prioritize critical requests, shed low-priority ones
• Implementation: Return HTTP 503 or silently drop at the load balancer
• Trade-off: Preserves latency for accepted requests at the cost of availability

A critical design choice in asynchronous systems. Unbounded queues can grow infinitely, leading to OutOfMemoryError. Bounded queues enforce a capacity limit and naturally create backpressure by blocking or rejecting producers when full.

• Unbounded: LinkedBlockingQueue without capacity
• Bounded: ArrayBlockingQueue(1000)
• Best Practice: Always use bounded queues in production pipelines

Push-based systems (e.g., raw Kafka consumers) deliver data as soon as it arrives, risking consumer overload. Pull-based systems (e.g., Reactive Streams) let the consumer request data, naturally implementing backpressure.

• Push: Producer controls the rate; requires explicit throttling
• Pull: Consumer controls the rate; backpressure is inherent
• Hybrid: Push with a dynamic rate limiter based on consumer health