Write a consumer that processes a stream with a bounded buffer and applies backpressure.

How to answer

The interviewer is testing three things: that memory stays bounded however fast the stream arrives, that you chose what happens when the buffer is full, and that the consumer stops cleanly. Say all three before writing code.

1. Ask the question that decides the policy. Can the source wait? A pull-based source such as a log or a paginated API can: if you stop reading, nothing is lost, so the full-buffer policy is to block, and that is backpressure. A push source such as a webhook burst or a sensor feed can’t, so you shed load, drop and count it, or spill to disk. Also ask about ordering, and whether an item may be processed twice.
2. State the memory bound out loud. A bounded queue, a reader that waits when the queue is full, and a fixed number of workers. The most items held at once is capacity + workers + 1: the buffer, one per worker and the one the reader is holding.
3. Isolate failures per item. A handler error goes to a dead-letter path and is counted; the worker keeps going.
4. Design shutdown as its own step. Stop reading, drain what is buffered, give up after a deadline, and report what was abandoned. Commit only the highest offset below which every item has finished, not each item’s offset as it finishes, because with several workers a later item can finish before an earlier one. Then anything abandoned is redelivered rather than lost.
5. Test the bound, not the speed. Block the handler, then assert how many items were pulled from the source.

The trap is the unbounded buffer in disguise: a queue with no maximum, or a task spawned per message. Both pass a demo and hold the whole backlog in memory the first time the downstream slows. Say which one you are avoiding before the interviewer asks.