Backpressure in Distributed System

You build a data pipeline. A fast "producer" service generates 10,000 events per second and puts them on a queue. A slower "consumer" service pulls them off to write to a database, but it can only handle 1,000 per second.

At first, it's fine. But the queue starts growing... and growing... until it exhausts all available memory and crashes.

1/ The magic keyword is Backpressure.

This is what happens when a downstream component is overwhelmed and needs a way to signal to the upstream component: "STOP! I can't handle any more right now."

Your job isn't just to connect two services with a queue. It's to create a feedback loop so the slow consumer can protect itself from the fast producer.

2/ The naive design has no feedback loop.

• The producer is stateless and happy. It just sends data as fast as it can.

• The queue is a buffer that hides the speed mismatch, but it's a buffer with a finite limit.

• The consumer is drowning.

The queue's eventual crash brings the whole system down.

3/ A robust streaming system implements backpressure.

There are many strategies, but a common one is a "pull-based" model. The consumer doesn't just passively receive data. It actively requests it.

The consumer says to the producer, "I have capacity for 1,000 items. Send them." The producer sends 1,000 items and then stops. It waits until the consumer comes back and says, "Okay, I'm done. I have capacity for another 1,000."

4/ The rate of processing is now dictated by the slowest component in the chain. The queue never grows uncontrollably because the producer is not allowed to get too far ahead of the consumer.

This is a core feature of modern streaming frameworks like Akka Streams, RxJava, and Project Reactor.

5/ So the real design question isn't: "How does a producer send data to a consumer?"

It's: "How does a consumer tell the producer to slow down, so that the system operates at a sustainable pace without crashing?"