What is backpressure, physically?
“A producer sends faster than a consumer can handle. Explain, layer by layer, what happens in the kernel and on the network — and why a slow consumer can freeze a fast producer.”
What this tests
- TCP flow control as a real mechanism (rwnd, zero window)
- The chain: unread receive buffer → zero window → full send buffer → blocked send()
- Bounded vs unbounded buffers and where memory goes
- Design responses: drop, buffer, slow down, shed
Answers by level
Read the beginner answer first and notice what is missing.
Start at the consumer: if the application does not call recv(), bytes accumulate in the socket receive buffer. Every ACK the consumer’s kernel sends advertises how much space is left (rwnd); when the buffer is full it advertises zero.
The producer’s kernel may not send beyond the advertised window, so the producer’s send buffer fills next. When it is full, send() blocks (or returns EAGAIN), and the producer thread stops — a slow consumer has frozen a fast producer through nothing but two bounded buffers and a window field.
That is backpressure: the pressure propagates backwards through every bounded queue. It is a feature — the alternative is unbounded buffering, which is a memory leak with a delay. The failure is when someone breaks the chain: a user-space queue with no bound absorbs the pressure until the process is OOM-killed.
Green flags · Red flags
ss -tin.- Traces receive buffer → rwnd = 0 → send buffer → blocked send()
- Calls backpressure a feature and unbounded buffers the bug
- Names an application-level equivalent (drain, request(n), consumer lag)
- Distinguishes buffering, dropping and slowing down
- "TCP handles it" with no mechanism
- Proposes a bigger buffer as the fix
- Confuses flow control with congestion control
- Does not see that a blocked thread in the consumer is the trigger