On a reader's assigned share, does one record that cannot be handled block the records behind it or only itself?

middleshould knowfreq 55%

answer

what is the unit of recorded progress?
one advancing point, or marks per record
the blast radius is the share
later work done, position still parked
per-key order blocks its key only

basics

~20 s

It depends on the unit of recorded progress. Where a share's progress is one advancing read position, the record blocks everything behind it on that share. Where each record is acknowledged on its own, it blocks only itself.

solid answer

~50 s

The blocking is not a property of the record; it is a property of how progress is recorded. On designs where a reader's place in a share is a single advancing read position, that point cannot legally move past a record that never completed, so everything behind it on that share waits — even records that would have succeeded. On designs where every record is acknowledged individually and removed when acknowledged, a failing record blocks only itself; it comes back after its holding window and the rest keep flowing, though it consumes a delivery attempt each cycle. A third case sits between them: where order is preserved per key group, one bad record blocks its key and nothing else. The practical consequence is blast radius — a share, one record, or one key — and that is what you need to know before choosing how to unblock it.

The blocking is not a property of the record; it is a property of how progress is recorded. On designs where a reader's place in a share is a single advancing **read position**, that point cannot legally move past a record that never completed, so everything behind it on that share waits — even records that would have succeeded. On designs where every record is acknowledged individually and removed when acknowledged, a failing record blocks only itself; it comes back after its holding window and the rest keep flowing, though it consumes a delivery attempt each cycle. A third case sits between them: where order is preserved per key group, one bad record blocks its key and nothing else. The practical consequence is blast radius — a share, one record, or one key — and that is what you need to know before choosing how to unblock it.

go deeper

for a junior

Recall that a reader has a recorded place it has reached, and that a record it cannot finish may hold up the records behind it. Know that this depends on how progress is stored.

for a middle

Explain the mechanism: a single advancing position means everything before it is done, so it cannot move past an incomplete record, while per-record acknowledgement has no such wall. Name the per-key case as the third answer.

for a senior

Reason about blast radius and urgency — one frozen share is a growing backlog ageing towards the retained window, whereas one circulating record is a capacity cost — and choose the unblocking action from that.

for a principal

Treat the unit of progress as a design input, not a detail: it sets how much one unhandleable record can cost, and it should be known before a stream carrying per-entity ordering is placed on a given platform.

The unit of progress decides the blast radius

A reader that stalls on one record raises a question the interviewer actually cares about: how much stops? The answer is not about the record. It is about what the system records as progress, and there are three shapes in common use.

One advancing point per share. The reader's place is a single read position over an ordered share. Progress means moving that point forward.
A mark per record. Each record is acknowledged on its own and removed when acknowledged; there is no single point to advance.
One advancing point per key group. Order is kept for records sharing a key, and progress is per key rather than per share or per record.

Each shape gives a different answer to "what is blocked", and a candidate who gives only one answer has described the platform they know rather than the class.

Where progress is one advancing point

The position means everything before this is done. That is what makes it cheap to store and cheap to resume from — one number restores a reader's whole state. It is also exactly why a record that never completes is a wall: the point cannot be moved past it without asserting something false about the record.

Records behind it on that share are unaffected in themselves; they simply cannot be counted as done.
Many clients will happily process later records anyway, holding the completions in memory. The recorded position still cannot advance past the earliest incomplete record, so a restart re-does all of that work.
The freeze is scoped to the share. Other shares of the same stream, held by other members, keep moving. This is what makes the failure survivable and what makes it easy to miss.
The backlog behind the record keeps growing, and its oldest entries age towards the edge of the retained window. A blocked share is therefore a clock, not a steady state.

Where each record is acknowledged on its own

There is no ordered point to be stuck behind, so the failing record blocks only itself. It is still not free:

Each cycle it is delivered again after its holding window and consumes a delivery attempt and a handler's time.
Many such records accumulating consume real capacity, so a population of unhandleable records becomes a throughput problem rather than a blocking one.
Because members compete for the same work rather than owning shares, the failure attributes to the record, not to a member. The same record will circulate through every reader in turn.

When ordering adds a third answer

Where a design guarantees order within a key group, an unhandleable record for a key holds that key's subsequent records and nothing else. Records of other keys keep flowing through the same reader. This is the intermediate case, and it is the one most likely to be described wrongly, because it looks like per-record independence right up until a second record for the same key arrives.

The three shapes side by side

how progress is recorded	what one unhandleable record blocks	what it still costs when it blocks nothing
one advancing point per share	every unread record behind it on that share	the share's backlog ages towards the retained window
a mark per record	only itself	a delivery attempt and handler time on every cycle
one advancing point per key group	later records of the same key	other keys keep flowing, so it hides in the aggregate

What this changes when you are staring at it

Establish the shape first. Ask whether a restart would re-do work already completed. If yes, progress is one advancing point and you are looking at head-of-line blocking.
Size the damage from the shape, not from the chart. One frozen share out of many barely moves an aggregate, and per-key blocking barely moves anything at all — yet both can be losing work for one customer entirely.
Choose the exit accordingly. Head-of-line blocking is urgent because the wall holds a growing backlog. A record that blocks only itself can often wait for a proper fix, provided the population of such records is small and is being counted.

The common mis-statements

"One bad record stops the stream." It stops a share, or a key, or nothing but itself.
"Processing the later records fixes it." It fixes throughput in memory and not the recorded position, which is what survives a restart.
"Per-record acknowledgement means bad records are harmless." They circulate, and circulation is capacity.
"Blocking means the broker is refusing to deliver." Delivery is usually fine; it is the recording of progress that cannot move.

## The unit of progress decides the blast radius A reader that stalls on one record raises a question the interviewer actually cares about: how much stops? The answer is not about the record. It is about what the system records as *progress*, and there are three shapes in common use. - **One advancing point per share.** The reader's place is a single **read position** over an ordered share. Progress means moving that point forward. - **A mark per record.** Each record is acknowledged on its own and removed when acknowledged; there is no single point to advance. - **One advancing point per key group.** Order is kept for records sharing a key, and progress is per key rather than per share or per record. Each shape gives a different answer to "what is blocked", and a candidate who gives only one answer has described the platform they know rather than the class. ## Where progress is one advancing point The position means *everything before this is done*. That is what makes it cheap to store and cheap to resume from — one number restores a reader's whole state. It is also exactly why a record that never completes is a wall: the point cannot be moved past it without asserting something false about the record. - Records behind it on that share are unaffected in themselves; they simply cannot be counted as done. - Many clients will happily process later records anyway, holding the completions in memory. The recorded position still cannot advance past the earliest incomplete record, so a restart re-does all of that work. - The freeze is scoped to the **share**. Other shares of the same stream, held by other members, keep moving. This is what makes the failure survivable and what makes it easy to miss. - The backlog behind the record keeps growing, and its oldest entries age towards the edge of the **retained window**. A blocked share is therefore a clock, not a steady state. ## Where each record is acknowledged on its own There is no ordered point to be stuck behind, so the failing record blocks only itself. It is still not free: - Each cycle it is delivered again after its holding window and consumes a delivery attempt and a handler's time. - Many such records accumulating consume real capacity, so a population of unhandleable records becomes a throughput problem rather than a blocking one. - Because members compete for the same work rather than owning shares, the failure attributes to the record, not to a member. The same record will circulate through every reader in turn. ## When ordering adds a third answer Where a design guarantees order within a key group, an unhandleable record for a key holds that key's subsequent records and nothing else. Records of other keys keep flowing through the same reader. This is the intermediate case, and it is the one most likely to be described wrongly, because it looks like per-record independence right up until a second record for the same key arrives. ## The three shapes side by side | how progress is recorded | what one unhandleable record blocks | what it still costs when it blocks nothing | |---|---|---| | one advancing point per share | every unread record behind it on that share | the share's backlog ages towards the retained window | | a mark per record | only itself | a delivery attempt and handler time on every cycle | | one advancing point per key group | later records of the same key | other keys keep flowing, so it hides in the aggregate | ## What this changes when you are staring at it 1. **Establish the shape first.** Ask whether a restart would re-do work already completed. If yes, progress is one advancing point and you are looking at head-of-line blocking. 2. **Size the damage from the shape, not from the chart.** One frozen share out of many barely moves an aggregate, and per-key blocking barely moves anything at all — yet both can be losing work for one customer entirely. 3. **Choose the exit accordingly.** Head-of-line blocking is urgent because the wall holds a growing backlog. A record that blocks only itself can often wait for a proper fix, provided the population of such records is small and is being counted. ## The common mis-statements - "One bad record stops the stream." It stops a share, or a key, or nothing but itself. - "Processing the later records fixes it." It fixes throughput in memory and not the recorded position, which is what survives a restart. - "Per-record acknowledgement means bad records are harmless." They circulate, and circulation is capacity. - "Blocking means the broker is refusing to deliver." Delivery is usually fine; it is the recording of progress that cannot move.

If a client keeps processing records behind the blocked one, why is the problem not solved?
Because the durable statement of progress is the recorded position, and it can only be advanced to the earliest incomplete record. The later completions exist in memory only. A restart, a reassignment or a crash discards them and the work is done again. The client has bought throughput, not progress, and has quietly made duplicate side effects more likely on the next resume.
Does head-of-line blocking mean the broker has stopped delivering records?
No. Delivery is generally unaffected: records behind the wall exist and can be fetched. What cannot move is the recorded position, because advancing it would assert that the incomplete record is done. Treating this as a broker fault sends operators to look at the cluster when the state that matters lives in the reader's own recorded progress.
How do you spot per-key blocking, given the aggregate barely moves?
Watch the age of the oldest unread record rather than the count, and break it down by key where the design exposes that. A handful of keys frozen for hours produces a negligible count and an extreme age, so a count-only view reports health while specific customers are entirely stalled behind one record each.

A bookmark can only sit at the page you have genuinely finished. You may have read three pages further on, but if page 40 defeats you the bookmark stays at 40, and to anyone who picks the book up later you have read nothing past it. A tray of separate forms behaves differently: one form you cannot fill in sits in the tray while every other form is stamped and filed around it.

saying these in an interview costs you the question

Claims one failing record always blocks everything behind it
Says the whole stream stops when only one share is frozen
Thinks completing later records advances the recorded position past the gap
Assumes per-record acknowledgement makes a failing record cost nothing
Describes blocking as the broker refusing to deliver records
Misses the per-key case between share-wide and record-only blocking

On a reader's assigned share, does one record that cannot be handled block the records behind it or only itself?

§ answer

basics

solid answer

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The unit of progress decides the blast radius

Where progress is one advancing point

Where each record is acknowledged on its own

When ordering adds a third answer

The three shapes side by side

What this changes when you are staring at it

The common mis-statements

▾common follow-ups3 questions

▾analogy~30 s

▾red flags6 flags

The unit of progress decides the blast radius

Where progress is one advancing point

Where each record is acknowledged on its own

When ordering adds a third answer

The three shapes side by side

What this changes when you are staring at it

The common mis-statements

answer

go deeper