Phones stamp each order with their own clock and some records arrive dated a week in the future. What does grouping by the receiving system's stamp buy, and what does it cost?
answer
- whose clock wrote it
- authority against fidelity
- receipt is stamped on your side
- the offline gap is real data
- keep both, compare the pair
basics
~20 sIt buys a moment set on your side of the boundary that no producer can invent, and it costs the offline gap: an order placed in a tunnel and uploaded four hours later is now counted four hours late, and the delay you were measuring disappears.
solid answer
~50 sReceipt time — the moment the system that first accepted the record stamped it — is set by infrastructure you operate, so a producer with a wrong clock cannot place a record in the wrong week. That is a real gain, and it also protects anything downstream that relies on the moments being roughly sane. What it costs is fidelity: the gap between when something happened and when it could be transmitted is exactly what the payload moment preserves and receipt time erases, and for a mobile source that gap is the interesting part of the data. The usual answer is not to swap one for the other but to keep both — nominate the payload moment, keep the receipt stamp alongside it, and decide explicitly what happens to a record whose payload moment is implausible against it.
go deeper
Know that a moment written by a device you do not control can be wrong, and that the system receiving the record can stamp its own moment as an alternative.
Explain the trade in both directions: the receipt stamp cannot be invented by a producer, but it absorbs the gap between an event happening and being transmitted, which for an offline-capable client is the interesting part.
Design the rule rather than picking a side: nominate the payload moment, retain the receipt stamp, define plausibility against the pair, and count how often the substitution fires so a degrading source is visible.
Decide what a published figure is defined on and what consumers may rely on, so a change of that definition is a deliberate, announced change rather than a quiet shift in every number built on it.
## The trade the question is really about The three candidate moments differ in one respect that matters here: **who set them**. The payload stamp was set by the producer, which may be a device you do not operate, do not configure and cannot audit. The receipt stamp was set by the system that first accepted the record, which is yours. The worker's wall clock is yours too but describes the run rather than the record, so it is not in this trade. | property | payload stamp | receipt stamp | |---|---|---| | authority | the producer | the system that accepted the record | | can be implausible or in the future | yes | no, by construction | | preserves the delay between happening and transmission | yes | no — it absorbs it | | available when the producer wrote nothing usable | no | yes, if the stamp is exposed | | answers "when did this happen" | yes | only when transmission is prompt | Switching to receipt time is therefore not a correctness fix; it is a swap of one failure mode for another. You stop being exposed to a producer's stamp and start being exposed to the transport. ## What the future-dated record actually breaks A record dated a week ahead is worse than a single wrong row, and it is worth being able to name the consequences: - It is filed in a bucket for a period that has not happened yet, so it is invisible in every report until that period arrives and then appears in it. - Anything the job maintains for that bucket has to be retained until then, which extends what the job is holding by the size of the mis-stamp. - If the job derives a running claim about what is no longer expected to arrive from the moments it sees, one future-dated record can drag that claim forward and make every genuinely current record look old. That handling is its own subject, but this choice is what causes it. - Symmetrically, a record dated years in the past is filed in a period long since reported and may simply be discarded. ## The answer that keeps both In practice the strong option is rarely "receipt instead of payload". It is: 1. **Nominate the payload moment** as the record's time, because the number is a claim about the world and the offline gap is real data. 2. **Keep the receipt stamp on the record** as a second field rather than discarding it. 3. **Define plausibility against the pair.** A payload moment after the receipt stamp is impossible in the world and is a sure sign of a wrong producer clock; a payload moment implausibly far before it is a second, weaker signal. 4. **Decide what happens to an implausible record** — clamp it to the receipt stamp and mark it as substituted, divert it for inspection, or reject it — and count how often the rule fires. The count is what tells you the source has degraded. 5. **Say which choice the published figure is on**, so nobody reads a receipt-based number as a statement about when customers acted. Rule 3 is the part people skip, and it is the part that does the work: the receipt stamp is useful mainly as the yardstick that makes a bad payload stamp detectable, not as a replacement for it. ## Where it varies The availability of the middle option is not universal, so check before designing around it: - Not every receiving system stamps records, and not every one exposes its stamp to the job as readable metadata. - Where the stamp exists, what it means differs — the instant of acceptance, the instant of durable write, or the instant a batch of records was committed together — and a batch-committed stamp gives many records the identical moment, which affects any ordering built on it. - An engine that only ever reads a finished bounded input may be given files whose records carry no receipt stamp at all, in which case the payload moment or a file-level stamp is all there is. ## The judgment to show The interviewer is listening for whether you treat this as a setting or as a promise. A candidate who says "use receipt time, device clocks are unreliable" has solved the visible problem and silently deleted the offline behaviour of the product from the data. A strong answer names the trade in one sentence — authority against fidelity — chooses the payload moment for a figure about the world, and then explains the plausibility rule and the counter that makes the bad records visible instead of invisible.
- How do you detect a producer with a wrong clock without knowing the truth?Compare each record's payload moment against the receipt stamp on the same record. A payload moment later than the receipt stamp is impossible in the world and is conclusive. A distribution of that difference per producer or per client version turns it into a monitorable signal: one cohort shifting by hours is a bad release or a timezone bug, not user behaviour.
- Why not just clamp any future-dated payload moment to the receipt stamp and move on?That is a reasonable rule, but only if the substitution is marked on the record and counted. Unmarked, the data now mixes two different moments with no way to tell which is which, and the count is the only thing that would have told you a client release started emitting bad stamps. The repair is fine; hiding it is not.
saying these in an interview costs you the question
- Switches to the receipt stamp and never mentions what was lost
- Treats a future-dated record as a single bad row with no wider effect
- Assumes every receiving system stamps records and exposes the stamp
- Discards the receipt stamp once the payload moment is nominated
- Silently clamps implausible moments without counting how often it happens
- Says the device clock problem is solved by asking producers to synchronise