On a broker that stores no read position and deletes each record once acknowledged, what does resetting forward mean, and is there a way back?
answer
- no bookmark, no move
- forward becomes discard the waiting records
- the loss is shared by every reader
- a second pass needs a copy made earlier
basics
~20 sForward means purging the waiting records — discarding them for every reader at once — because there is no bookmark to move. There is no way back: reprocessing requires a second copy written when the records were first produced.
solid answer
~50 sWhere a record is removed as soon as it is acknowledged, progress is the disappearance of records rather than a number someone stores, so there is nothing to write a new value into. The nearest thing to a forward move is a purge: discard what is waiting. It is immediate, it is usually all-or-nothing for that stream, and it takes the records from every reader that would have received them, not just from the group you were thinking about. There is no backward equivalent at all — the records are gone, and the only source of a second pass is a copy written elsewhere at the time they were produced. That makes the interesting decision an architectural one taken long before the incident, and it makes the operator's options during the incident two: purge, or drain the waiting records somewhere you can read later if the platform allows moving them.
go deeper
Remember the dependency: moving a read position only exists where something records one. Where a record disappears as soon as it is acknowledged, there is no place to move and nothing behind the reader to go back to.
Explain why the forward equivalent is discarding the waiting records and the backward equivalent does not exist, and describe read-and-discard as the selective option that trades speed for control.
Show the operator's judgement: name the discard as irreversible and shared across every reader of the stream, scope it before running it, and state that a second pass depends on a copy made when the records were produced.
Own the design consequence: whether the estate needs reprocessing at all decides whether records must survive being read or a parallel archive must be paid for, and that call is made long before the incident that needs it.
## Where the bookmark does not exist The whole vocabulary of moving a read position assumes a design that keeps a record after it has been read and keeps a **stored position** saying how far a reader group has got. A large part of this product class does neither: a record is delivered, and when the reader acknowledges it the broker removes it. Progress is not a number — it is the absence of the records already handled. That single difference removes both halves of the operation: - **There is no value to write.** No forward move, no backward move, no per-share position to capture beforehand. - **There is nothing behind the reader to go back to.** The span already handled does not exist in the broker any more. Saying "you can always rewind a reader" is the most common way this subject is got wrong, and it describes one model rather than the class. ## What forward becomes: the purge The operational equivalent of abandoning a backlog is **discarding the waiting records**. Its character is different from a position move in three ways that matter during an incident: - **It destroys data, not a bookmark.** A forward position move leaves the records in place for anyone else; a purge removes them. - **It is shared.** Every reader that would have received those records loses them, so the blast radius is the stream, not the group. - **Its granularity is usually coarse.** Many implementations offer only "discard what is waiting", not "discard everything older than a chosen point". Where selective discard exists it is usually implemented by *receiving* the records and disposing of them individually, which costs the same read throughput as processing them. That last point gives the operator the one selective option available: **read and discard**. Run the readers with the handler disabled or short-circuited so they acknowledge without acting. It is slower than a purge, it is bounded by the same delivery rate, and it is observable and stoppable partway — which is often worth more than speed. ## What backward becomes: nothing, unless it was planned There is no operator action that brings acknowledged records back. A second pass over yesterday's work is possible only if a second copy was written **when the records were first produced**: 1. The producer also wrote to a durable store or an archive. 2. The broker was configured to copy deliveries to a second stream that nobody drains destructively. 3. Some downstream component retained the payloads — a log of handled work, an audit trail. All three are decisions taken before the incident. This is the practical reason teams whose recovery story depends on reprocessing choose a design that retains records independently of reading, or pay for a parallel archive on one that does not. ## The two models side by side | | record kept after reading, position stored | record deleted on acknowledgement | |---|---|---| | abandon a backlog | move the position forward; records remain for others | purge the waiting records; they are gone for everyone | | reprocess a span | move the position backward, while the records are still held | not possible from the broker; needs a copy written at production time | | reversible? | from a recorded prior position, while the records remain | no | | blast radius of the action | the one reader group | every reader of that stream | | granularity | any point, per share | usually all-or-nothing, unless you read and discard | ## A third shape to be ready for Some designs delete on acknowledgement but keep the position **outside the broker** — in a side table the application owns, or in the reader itself. Then a move is an edit to that table: it is available, but nothing validates it, nothing refuses it while readers are live, and nothing records the prior value unless the operator does. The stop-first and capture-first discipline matters more there, not less, because the platform supplies no interlock at all. ## What an interviewer is listening for The signal is whether a candidate reaches for "reset the position" as a universal tool or asks first what the design stores. The strong answer names the purge as the forward equivalent, says out loud that it is irreversible and shared, offers read-and-discard as the selective alternative, and points out that the ability to reprocess at all was decided when the system was designed rather than when it broke.
- What is the selective alternative when discarding everything is too blunt?Read and discard: run the readers with the handler disabled so they acknowledge without acting. It costs the same delivery throughput as processing and takes as long, but it can be scoped, watched and stopped partway, which a single destructive discard cannot.
- If the position is held in the application's own table rather than the broker, does the procedure change?The steps are the same and the guardrails are weaker. Nothing refuses the edit while readers are live and nothing keeps the prior value, so stopping every member first and recording the old numbers by hand carries the whole weight of the operation.
- Why is discarding the waiting records riskier than moving a position forward?A position move affects one reader group and leaves the records for anyone else reading them. A discard removes the records themselves, so every reader of that stream loses them at once, and there is no prior value to restore afterwards.
saying these in an interview costs you the question
- Assumes every broker has a position that can be rewound
- Thinks discarding waiting records affects only one reader group
- Believes acknowledged records can be restored by an operator
- Expects a discard to be limited to records older than a chosen time
- Treats an archive written at production time as unnecessary