Reactive programming allows developers to build highly responsive and scalable systems that handle asynchronous data flows. But a fundamental challenge emerges when producers emit data faster than consumers can process it.
Without a solution, this imbalance leads to memory overload, CPU exhaustion, and cascading failures. The solution is backpressure.
What is Backpressure?
Backpressure is the mechanism that allows a consumer to communicate to its producer that it cannot keep up with the current data rate. Rather than silently dropping messages or crashing under load, a well-designed reactive system uses backpressure to apply flow control.
Think of it like a water pipe: if you push water in faster than it can flow out, something bursts. Backpressure is the pressure relief valve.
Why It Matters
Without proper backpressure handling:
- Memory overload — unbounded buffers fill up and cause OOM errors
- CPU exhaustion — the consumer thrashes trying to process an overwhelming queue
- Cascading failures — one slow consumer can destabilise an entire pipeline
- Silent data loss — messages get dropped without any indication
Four Core Backpressure Strategies
1. Buffering
Temporarily store excess data in a bounded buffer. When the buffer fills, apply additional pressure upstream.
// Project Reactor
Flux.range(1, 1000)
.onBackpressureBuffer(100) // buffer up to 100 items
.subscribe(item -> process(item));
Use when: Data loss is unacceptable and consumers will eventually catch up. Be careful with buffer size — an unbounded buffer is no protection at all.
2. Dropping
Discard items when the consumer falls behind. Simpler than buffering, but only appropriate when losing some messages is acceptable.
// RxJava
Flowable.interval(1, TimeUnit.MILLISECONDS)
.onBackpressureDrop()
.observeOn(Schedulers.computation())
.subscribe(item -> slowProcess(item));
Use when: You’re processing real-time streams (metrics, sensor data) where stale data has no value.
3. Throttling
Control the emission speed from the producer to match consumer capacity. Instead of buffering or dropping, you slow the source down.
// Akka Streams
Source.repeat("event")
.throttle(10, Duration.ofSeconds(1)) // max 10 elements per second
.runWith(Sink.foreach(System.out::println), system);
Use when: The producer is controllable and you want to maintain a steady, sustainable flow rather than bursts.
4. Requesting (Pull-based)
Consumers explicitly request a specific number of items from the producer. This is the most precise form of backpressure — the foundation of the Reactive Streams specification.
// Project Reactor — limit rate to 10 items at a time
Flux.range(1, 1000)
.limitRate(10) // consumer pulls 10 items at a time
.subscribe(item -> process(item));
Use when: You want fine-grained control over throughput and can predict consumer processing capacity.
Framework Comparison
| Framework | Default Strategy | Key API |
|---|---|---|
| Project Reactor | Error on overflow | onBackpressureBuffer(), limitRate() |
| RxJava | Configurable | onBackpressureDrop(), onBackpressureLatest() |
| Akka Streams | Built-in propagation | throttle(), buffer() |
All three follow the Reactive Streams specification, which standardises backpressure handling through the Publisher/Subscriber contract.
Best Practices
- Match strategy to data criticality — financial transactions need buffering; live metrics can afford dropping
- Always bound your buffers — unbounded buffers defer the problem rather than solving it
- Test under realistic load — backpressure issues only surface at production traffic levels
- Understand your consumer’s processing capacity — profile before tuning
- Monitor queue depths — expose buffer utilisation as a metric to catch pressure building up
Key Takeaway
Backpressure isn’t an edge case — it’s a core concern in any reactive system that handles real-world load. Choosing the right strategy (buffer, drop, throttle, or request) depends on your data’s criticality and your consumer’s characteristics. The frameworks provide the tools; understanding the trade-offs is the engineering judgment that makes them work.