Why is every member of a reader group stopped before its recorded read position is moved, and what breaks if one keeps running?

## Two copies of one number A reader group's **read position** looks like a single stored value, but while the group is running there are really two copies: the one in the **position store** (broker-side, a side table, or wherever the design keeps it) and the one each member holds **in memory** as it works. The in-memory copy is authoritative for that member's behaviour; the stored copy is authoritative only for a member that is *starting*. Members reconcile the two by writing their in-memory value back — periodically, at a reassignment, and usually on a clean shutdown. Every hazard in this operation follows from those two copies existing at once. ## What a live member does to your move If an operator writes a new position while a member still holds the affected shares: - **The move is overwritten.** The member's next write-back stores the place it has actually reached, and the administrative value disappears. The group looks moved for a few seconds and then reverts — a symptom teams often misdiagnose as "the change did not apply". - **The move is ignored.** The member never re-reads the stored value while it is running, so it keeps reading from its in-memory place regardless. This is the more dangerous of the two, because a rewind that was meant to reprocess simply does not, and nobody notices until the missing output is reported. - **The move is applied to part of the group.** Shares held by stopped members take the new value; shares held by live members do not. The group is left split across two places in the stream, and the resulting output is neither the old behaviour nor the intended one. - **A reassignment lands in the middle of it.** If members are stopped one at a time, their shares are handed to the survivors as they go, and whichever member picks a share up next reads whatever value happens to be stored at that instant. The result depends on timing. Platforms vary in how much of this they let you do. **Some refuse the change while the group has live members**, which turns a silent data problem into a loud error message. **Others accept it and let the running member overwrite it.** Never assume you are on the protective kind; the procedure below is safe on both. ## Record the prior position before anything is touched The move overwrites the old value. There is generally no undo history, so once it is gone the answers to two separate questions are gone with it: 1. **How do we go back?** A rewind to the wrong place, or a forward move to a point that turns out to be too far, is recoverable only if the original number exists somewhere outside the position store. 2. **What exactly changed?** The span between the prior position and the new one is the span that was skipped or that will be reprocessed. That is the number the rest of the organisation needs — for the team whose output has a hole in it, for the people who will see duplicate effects, for the incident record. Record it **per share**, not as one number: on designs that split a stream into parts, each part has its own position and they are rarely at the same place. Capture the wall-clock time and the unread count too, because they let you say how far behind the group was, not only where it was. ## The procedure 1. **Capture** the current position of every share, plus the time and the unread count. 2. **Stop** every member of the group and confirm no member still holds a share — not "scale to one", not "pause the handler": stopped. 3. **Apply** the move, forward or backward, to every affected share. 4. **Read back** the stored positions and confirm they are the values you asked for. 5. **Restart** the readers and watch the gap move in the intended direction for the first minutes. Step 4 exists because steps 2 and 3 are the two that fail quietly. Step 5 exists because a group that comes back at the old place looks identical to one that came back at the new place, until you look at the direction the curve moves. ## Where the guard is weaker Where the position is not kept by the broker at all — held in a side table the application owns, or by the reader itself — nothing validates the move and nothing refuses it. The same discipline applies with more force: the operator is editing live state with no interlock, and "stop the readers first" is the only protection that exists. And where nothing stores a position, this procedure has no meaning: there is no value to capture and none to move, and the only forward-like action is discarding the waiting records.