A figure published from a never-ending input changed after a stakeholder read it. What contract should that output have carried, and what does it demand of the reader?
answer
- a missing promise, not a bug
- final, or current as of
- replace by key, never add
- the marker travels with the number
basics
~20 sSay whether the number is final or provisional. Over an input with no end a value is true only as of the records seen, so either freeze a bounded slice and publish once, or publish revisions with an as-of marker.
solid answer
~40 sThe fault is a missing contract, not a moving number. Over a bounded input the publisher can promise finality: the set is closed, so one value is computed, and as long as the input still exists unchanged a rerun of the same logic reproduces it. Over an input with no end that promise is not available, so the output has to say which weaker promise it is making — *final within this imposed boundary*, or *current as of these records and subject to revision*. The reader's side of the contract follows from that: replace by key rather than accumulate, tolerate a value that moves and an entry that disappears, store the as-of marker alongside the number so two reports cannot silently disagree, and never quote a provisional figure externally as though it were settled.
go deeper
Remember that a number computed from an input with no end is only true as of the records seen. Publishing it without saying that is what surprises the reader later.
Explain the choice between freezing a boundary and publishing revisions, and what each obliges the destination to do — replace by key rather than accumulate, and keep the marker with the value.
Locate the incident in the missing contract rather than the job, state which emission shape the runtime is on, and show how the destination's write semantics were matched to it or why they were not.
Make it policy: which figures may be published provisionally, which must be frozen before they leave, and who owns the reconciliation when the two disagree. Left to each team, this produces numbers nobody can defend.
## What an ending buys a publisher When the input has a last record, three promises are available at once, and teams rely on all three without noticing: - **One value.** The computation runs, emits, and is done. There is no second version of the same number to reconcile. - **Finality.** Nothing can arrive that changes it, so the number can be named without a timestamp and quoted outside the team. - **Reproducibility by recomputation.** As long as the input still exists unchanged and the logic is deterministic, running it again from the top yields the same answer — which is what makes "we found a bug, we reran it" a complete story. Remove the ending and all three go at once. That is the real content of the incident: nobody broke anything, the output was simply published under a contract that the input could not support. ## The contracts available when there is no ending | Contract | What the publisher promises | What the reader must do | What it costs | |---|---|---|---| | Final per imposed boundary | one value per closed slice, never revised | key results by the slice they describe | freshness: the latest figure is a boundary old | | Current as of a marker | the value is correct for the records seen up to the marker | replace by key, keep the marker, expect movement | readers must handle a number that moves | | Provisional then final | early values are marked provisional; one later value is marked final | ignore provisional values for anything quotable | two code paths downstream, and a marking discipline | | Full revision history | every emission is kept, each with its marker | read the latest per key, or reconstruct as of a past point | storage, and readers who forget to take the latest | None of these is the right answer everywhere. An internal dashboard is usually well served by "current as of"; anything leaving the organisation usually needs "final per boundary" precisely because the reader cannot be trusted to re-read it. ## Making a revision consumable 1. **Key the output by what it describes**, not by when it was written — the slice, or the entity and its as-of marker. A revision must be recognisable as the same logical answer, otherwise the destination has no way to know it supersedes anything. 2. **Make the write idempotent**: replacing a value by key means re-emitting it costs nothing. Appending it means a re-emission changes the total, which is how a single revision becomes double counting three tables downstream. 3. **Carry the as-of marker into the destination**, so a reader can see what a number covers, and two reports built from different reads can be compared rather than argued about. 4. **Say in the schema, not in a wiki, whether a value is provisional.** A flag the reader has to look up is a flag the reader will not look up. ## What varies between runtimes How revisions arrive is genuinely not uniform in this class of system, and the destination's write semantics have to match whichever shape the job is on: - some runtimes emit an **updated running result on every input record**, so revisions are the normal case and the destination must replace by key; - some emit **once per imposed boundary**, so the destination mostly sees one value per slice; - some emit an **early speculative value and a correction later**, so the same logical answer appears more than once and must never be summed. The destination's data model then decides what survives: overwriting a single row per key gives readers one coherent value but destroys the history, while appending every emission keeps the history and puts the burden of picking the latest on every reader. Choosing one silently is how two dashboards end up disagreeing with each other and both being right about what they read. ## Failure modes seen in practice - A running total is assumed to move in one direction, a correction or a reversal arrives, and a downstream alert that only tested for an increase never fires. - A downstream table sums every emission for a key, so one revision inflates the total permanently. - A provisional figure is screenshotted into a document that outlives it, and the final value is never propagated to the people holding the screenshot. - Someone "fixes" a revision by waiting longer before publishing. Waiting buys probability, never certainty, and how long to wait — and what to do about whatever arrives afterwards — is a separate subject with its own machinery. - The publisher treats a revision as a defect and suppresses it, which converts a visible correction into an invisible wrong number. The interviewer is listening for one move above all: that you locate the problem in the contract rather than in the job, and that you can state both what the publisher promises and what that obliges the reader to do.
- A downstream table sums every published value for a key. What breaks when a value is revised?The revision is added to the original instead of replacing it, so the total is permanently too high and nothing about it looks wrong locally. Either the publisher must emit deltas that are meant to be summed, or the destination must replace by key — and whichever it is has to be stated, because the two are indistinguishable from the shape of the data.
- Why is "wait a bit longer before publishing" not a general fix?Waiting raises the probability that the value is complete; it never makes it certain, and it spends latency to do so. It also does not tell the reader anything: an unmarked number published late is still a number that can change. How long to wait, and what to do with whatever turns up afterwards, belongs to the clock and completeness material, not here.
- When should a figure from an endless input be frozen to a boundary instead of published as a running value?Whenever the reader cannot be made to re-read it: invoices, regulatory returns, anything sent outside the company, anything a human will copy into a document. Freezing trades freshness for a value that can be quoted, and that trade is almost always correct once the number leaves the system that produced it.
saying these in an interview costs you the question
- Publishes from an endless input with no as-of marker
- Assumes a published running value can only move upward
- Calls a revision a bug in the job and suppresses it
- Sums revised values downstream instead of replacing them
- Believes waiting longer makes a number genuinely final