What happens to the waiting unread records when an operator moves a reader group's read position forward to the newest record?
answer
- a decision, not a repair
- the gap falls without work
- skipped records are never handed over
- reversible only from a recorded prior position
basics
~20 sMoving a reader group's read position forward abandons every record between the old position and the new one, so nothing processes them. The gap drops to zero at once because work was skipped, not done.
solid answer
~50 sA forward move is an administrative write to the reader group's recorded place in the stream, not an instruction to the readers to work harder. Everything between the old position and the new one is skipped: those records are never handed to that group, and whatever they would have caused downstream simply never happens. The visible effect is that the unread count and unread age collapse immediately, because both are measured from the position the operator just moved — which is exactly why a forward move can be mistaken for a recovery. On designs where records survive being read, the records themselves are untouched and other reader groups are unaffected; on designs that delete a record once it is acknowledged there is no position to move, and the only forward-like action is discarding the waiting records outright.
go deeper
Recall the one-line effect: the records between the old and new position are skipped and never processed, and the gap falls because the measurement moved, not because work happened.
Explain where the gap comes from — it is computed from the recorded position — and say what the move leaves untouched: the records themselves where the design retains them, other groups' positions, and the reason the group fell behind.
Show the operator's discipline: capture the prior position and the unread count first, name the skipped span by its boundaries afterwards, and tell the owners of the missing downstream effects rather than letting a green dashboard close the incident.
Set the policy in advance: which streams may be abandoned forward at all, who is allowed to authorise it, and what must be recorded — so that nobody improvises a data-loss decision at three in the morning under pressure to make a number go down.
## What a forward move actually touches A **read position** is the recorded point a reader group has reached in a stream — the bookmark that lets a restarted reader know where to carry on. It may be held by the broker, by a side table, or by the reader itself. Moving it **forward** is an administrative write to that bookmark and to nothing else: an operator sets it to a later point (the newest available record, a chosen time, or a chosen record) and the span in between is never handed to that group. Two consequences land the moment the readers resume: - **The skipped span is not processed.** Not later, not in the background, not by a retry. Whatever those records would have caused — an order picked, a counter incremented, a row written, a message sent onward — does not happen at all. - **The gap collapses.** The unread count (records still unread) and the unread age (the age of the oldest unread record) are both derived from the position. Move the position and both fall to near zero instantly. Nothing was handled; the measurement moved. That second point is why this operation is dangerous in a hurry: on a dashboard it is indistinguishable from a recovery. ## Why an operator chooses it anyway It is a legitimate, deliberate decision when the backlog of unread records is worth less than the delay it is causing: - The content is **stale by nature** — a feed where only the latest value per entity matters, so processing yesterday's values changes nothing except the time spent. - The backlog **cannot be drained before the records leave the retained window** anyway, so some of it will be lost regardless and the team chooses which part. - The backlog is **known-bad** — a producer emitted garbage for an hour and reprocessing it would only spread it further. - Fresh data now is worth more than complete data later, and the skipped span will be recovered by another route. In every case the honest statement is "we are choosing not to process these", not "we fixed the lag". ## What the move does not change | unchanged | why it matters | |---|---| | the records, where a design retains them independently of reading | the same span can be read again later if the prior position was recorded and the records are still held | | other reader groups' positions | each group keeps its own place, so a second group reading the same stream still sees the whole span | | the cause of the backlog | a slow handler, an undersized group or a stalled dependency is exactly as slow after the move | | downstream state | nothing is rolled back; the system simply has a hole where the skipped span's effects would have been | ## Forward against backward | | forward move | backward move | |---|---|---| | intent | abandon a backlog of unread records | reprocess records already read | | effect on the gap | collapses immediately | jumps up by the size of the rewind | | side effects | the skipped span's effects never fire | every effect downstream of the new position fires again | | what it costs | completeness | duplicate work and duplicate external effects | | reversible? | only from a recorded prior position, and only while the records are still held | same | ## Where the operation does not exist The whole idea assumes something stores how far the group has got. On designs that **delete each record once it is acknowledged**, progress *is* the disappearance of records: there is no bookmark to write. The nearest equivalent of a forward move is discarding the waiting records, which is immediate, total and takes them from every reader that would have received them. There is no backward equivalent at all. Describing a forward move as universally available is the most common way this subject is got wrong. ## Doing it defensibly 1. Write down the current position of every share, the time, and the unread count — that is the only record of what is being abandoned. 2. Stop every member of the reader group, so no live member writes its own position back over the move. 3. Apply the move, then read the stored positions back and confirm they say what was asked for. 4. Restart the readers and watch the gap behave as intended. 5. Report the skipped span by its boundaries, so whoever owns the missing effects can decide whether to recover them out of band. An interviewer is listening for step 1 and step 5 as much as for the mechanism: a candidate who treats a forward move as a repair rather than as a loss they signed for has not operated one.
- After a forward move, how do you say how much was skipped?From the numbers captured before the move: the prior position of each share against the position it was moved to, and the unread count at that moment. Nothing afterwards reconstructs it, because the old value was overwritten — which is the practical reason the prior position is written down first.
- Does a forward move on one reader group affect another group reading the same stream?Where each reader group keeps its own position, no — the second group still has the whole span in front of it. Where the design deletes records on acknowledgement and the forward-like action is discarding waiting records, yes: the records are gone for every reader that would have received them.
- Is moving the position forward the same as clearing the backlog of unread records?Only in the metric. Clearing a backlog means handling the records; a forward move means declaring they will not be handled. Both end with a small gap, and only one leaves the downstream effects in place.
It is the difference between reading the unread pages and moving the bookmark to the end. Where the book stays on the shelf, the pages are still there and someone else can still read them; where each page is torn out as it is read, moving to the end means the pages are gone.
saying these in an interview costs you the question
- Thinks a forward move makes the readers catch up faster
- Believes the skipped records are deleted from the stream by the move
- Assumes the move can be undone without knowing the prior position
- Treats a zero gap straight after the move as proof of recovery
- Expects other reader groups on the same stream to be moved too
- Assumes every broker has a position that can be moved at all