skip to content

A bounded buffer in a stream pipeline fills up - what do drop-newest, keep-latest and fail-fast each sacrifice?

level: middleimportance: must knowfreq 66%

answer

  1. four outcomes, not four safe ones
  2. each policy spends something different
  3. oldest survives, or the newest does
  4. buffering only defers the second rule
  5. only failure is loud

basics

~20 s

Bounded buffering spends memory and adds latency and only postpones the decision; dropping the newest arrival sacrifices freshness; keeping only the latest sacrifices every superseded value; failing fast sacrifices availability but is the only one that reports the loss.

solid answer

~40 s

Overflow policies are a price list, not a menu of equals. **Bounded buffering** admits every value while capacity lasts, paying memory and the delivery latency a deep queue adds - and it still needs a second rule for the moment it fills, so it defers the choice rather than removing it. **Dropping the newest arrival** leaves the queued values untouched, so the consumer processes an intact but increasingly stale prefix; freshness is what it spends. **Keeping only the latest** does the opposite: it evicts what is queued so the most recent value wins, spending every value that one supersedes. **Failing fast** ends the sequence with a failure signal - it gives up everything after the overflow point, but a subscriber learns of it, which the two discarding policies never arrange by themselves.

code

pseudocode · 14 lines
pseudocode
function onArrival(value):
    if count(buffer) < capacity:
        append(buffer, value)
        return

    if policy == DROP_NEWEST:
        discard(value)              // queued values survive, the arrival is lost

    else if policy == DROP_OLDEST:
        removeOldest(buffer)        // capacity 1 is the keep-only-latest case
        append(buffer, value)

    else if policy == FAIL:
        signalFailure("overflow")   // the sequence ends here

go deeper

for a junior

Learn the four outcomes by what they keep: everything for a while, the oldest, the newest, or nothing past the failure. Being able to name them and say that two of them throw values away is already a solid answer at this stage.

for a middle

Explain the mechanics: what happens to an arriving value at the instant the buffer is full under each policy, why buffering adds latency as well as spending memory, and why choosing to buffer means choosing a second rule for when capacity runs out.

for a senior

Show that you have watched one of these in production: the stale prefix a drop-newest stage delivers after a burst, the memory and latency a generous buffer bought, or the outage a fail-fast policy caused. Tie the policy to the symptom it produces.

for a principal

Frame it as a price list and make the payer explicit. Memory, latency, freshness and uptime are four different budgets owned by different people, and the overflow policy decides which budget absorbs a rate mismatch nobody has time to fix.

## Where the choice arises In a demand-driven stream the consumer signals upstream how many values it is prepared to take, and a producer that honours that demand never sends more, so overflow does not arise at all. An overflow policy belongs to the places where that chain is broken: a source with no way to honour demand, or a stage that deliberately decouples its input rate from its output rate behind a buffer of fixed size. There, values arrive faster than they leave, the space set aside for them is finite, and the pipeline has to be told what to do at the moment it runs out. The menu is short, and every entry on it spends something. ## What each policy spends | policy | what survives | what it spends | loses values? | |---|---|---|---| | **Bounded buffering** | every value, while capacity lasts | memory, plus the delivery latency a deep queue adds | not while there is room | | **Drop the newest arrival** | the values already queued, in order | freshness - the consumer falls further behind | yes, silently | | **Keep only the latest** | the most recent value | every value that one supersedes | yes, silently | | **Fail fast** | nothing after the overflow point | availability - the sequence ends | yes, and it says so | Bounded buffering buys time: it absorbs a burst whose average rate the consumer can still sustain, at the price of memory and of latency, because a value that waits behind a queue is delivered later than it was produced. Dropping the newest arrival refuses the incoming value and leaves the queue as it was. Keeping only the latest evicts what is already queued so that the freshest value is the one delivered; at capacity one it holds exactly the last value seen. Failing fast converts the overflow into a terminal failure signal that travels to the subscriber. ## Buffering defers the choice, it does not remove it The most common mistake is to treat buffering as a fourth, loss-free option and stop there. It is loss-free only while there is room: - A buffer of fixed size still needs a rule for the moment it fills, so choosing to buffer is choosing **two** policies, not one. - Time spent queued is added to every value's delivery latency, so a policy tuned for throughput can quietly break a freshness requirement. - Capacity decides **how long** a burst may last before the second policy fires; it does not decide **whether** it fires. The honest formulation is that buffering converts a rate mismatch into a deadline. If the consumer's sustained throughput exceeds the producer's sustained rate, the buffer drains between bursts and the second policy stays dormant. If it does not, the second policy is the real policy and capacity only chose when it starts. ## Which of them lose values, and how visibly - **Drop-newest and keep-latest both lose values, and both do it silently.** Nothing downstream can distinguish a stream that discarded nothing from one that discarded thousands, unless the discard was counted where it happened. - **They lose different values.** Drop-newest keeps the oldest and throws away the present; keep-latest keeps the present and throws away everything in between. For a feed whose items each supersede the last, keep-latest loses nothing the consumer wanted; for a feed whose items must all be seen, both are equally fatal. - **Failing loses more, and reports it.** It gives up every value after the overflow point, but the failure reaches a subscriber that can act on it. Silent loss cannot be acted on, because nobody learns of it. - **None of them makes the consumer faster.** Every entry is a way to survive a mismatch, not a way to remove one. ## How to answer it out loud 1. Say what the policy is for: the moment demand cannot be honoured and the space is gone. 2. Name what each entry spends - memory and latency, freshness, superseded values, availability - rather than reciting policy names. 3. Say which of them lose values silently, and add the sentence the interviewer is waiting for: whether that is acceptable depends on what a single item in this stream means. A candidate who lists the policies has answered half of it. The half that matters is the price list: someone pays in memory, latency, freshness or uptime, and choosing an overflow policy is choosing who pays.

  • Your buffer is sized so that it does not fill under normal traffic. Have you avoided choosing an overflow policy?
    No. Capacity chooses when the second rule fires, not whether it exists. A buffer that never fills in a normal week still fills during the abnormal hour that matters, and whatever the stage does then is your policy - usually an unexamined default. Size the buffer for the burst you expect, then state explicitly what happens past it.
  • After a long overflow under drop-newest, what does the consumer actually receive, and why is that often the worst outcome?
    It receives the values that were queued when the overflow began - a contiguous but old prefix - while everything produced during the overflow is gone. The consumer is therefore both behind and unaware of it. For anything freshness-driven that is the worst of the menu: you paid memory to preserve exactly the values whose usefulness had already expired.

A fixed-size mailbox that is full: refuse new letters, throw away everything but the newest, or return them marked undeliverable. Only the last one tells the sender anything happened.

saying these in an interview costs you the question

  • Thinks a bigger buffer removes the need for a policy
  • Calls bounded buffering lossless without asking what happens when it fills
  • Assumes dropping the newest and keeping the latest discard the same values
  • Believes a discarded value is re-offered once space frees up
  • Treats failing the stream as always the safest choice