Backpressure
Backpressure is a flow control mechanism where a slow consumer signals the producer to slow down, preventing buffer overflow and data loss. TCP's receive window is backpressure. In streaming systems (Kafka, reactive streams), backpressure propagates upstream – if the database is slow, the entire pipeline slows instead of dropping data.
Definition
Backpressure propagates flow control signals from slow consumers upstream to fast producers. Without backpressure, a fast producer overwhelms a slow consumer – buffers fill, memory exhausts, and data is lost or the system crashes. TCP implements backpressure via the receive window: when the receiver's buffer is full, it advertises rwnd=0, pausing the sender. In reactive programming (Project Reactor, RxJava, Akka Streams), backpressure is a first-class concept – subscribers request N items at a time, and publishers respect the demand signal. In message queues: Kafka consumers with consumer lag apply backpressure by not committing offsets (messages remain available for reprocessing). RabbitMQ applies backpressure by blocking publishers when memory or disk thresholds are breached. The alternative to backpressure is dropping: UDP has no backpressure – overloaded receivers simply discard packets. Choose based on data value: financial transactions need backpressure (no loss), telemetry metrics can drop (latest value is sufficient).
Examples
- –TCP: rwnd=0 in ACK pauses the sender (kernel-level backpressure)
- –Reactor: Flux.create(sink -> {...}, FluxSink.OverflowStrategy.ERROR)
- –RabbitMQ: vm_memory_high_watermark = 0.4 (blocks publishers at 40% RAM)
Related Protocols
Related Terms
Congestion
Network congestion occurs when traffic exceeds link or buffer capacity, causing packet loss and increased latency. TCP congestion control algorithms (Cubic, BBR, Reno) dynamically adjust sending rate to avoid overwhelming the network. Persistent congestion degrades all traffic on the shared path.
Flow Control
Flow control prevents a fast sender from overwhelming a slow receiver. TCP uses a receive window (rwnd) advertised by the receiver to limit in-flight data. If the receiver's buffer fills, it shrinks rwnd to zero, pausing the sender until the application drains the buffer.
Rate Limiting
Rate limiting restricts the number of requests a client can make in a time window. Prevents abuse (brute force, scraping), protects backend resources, and ensures fair usage. Algorithms: fixed window, sliding window, token bucket, leaky bucket. Return HTTP 429 Too Many Requests with Retry-After header when limits are exceeded.