Align Telemetry Streams and Publish Versioned Corrections

Two telemetry streams contain timestamped numeric observations. You need to subtract the streams and then handle late events that can change an earlier result. Explain the timestamp-alignment contract, an ordered-stream processing approach, and a reconciliation protocol that lets consumers distinguish initial results from corrections. ### Requirements and Constraints Within each initially supplied stream, timestamps are nondecreasing. A timestamp may occur in only one stream, and nondecreasing order does not rule out duplicate timestamps. The behavior for a missing counterpart and the meaning of duplicates have not been specified. Identify those decisions before proposing an algorithm. Later events may arrive after an initial result has been emitted. This is an engineering discussion about defining and maintaining the result contract. No fixed missing-value policy, event schema, lateness bound, or exactly-once delivery guarantee is assumed. ### Clarifying Questions - Are observations independent point measurements, additive contributions, or updates to a value that remains in effect until replaced? - At a timestamp present in only one stream, should the result be omitted, marked incomplete, interpolated, or computed using a defined default? - Do repeated timestamps represent distinct measurements, duplicates of one event, or revisions to an earlier value? - How late can events arrive, and must consumers support replacement values, delta corrections, or both? ```hint Define the result key before correcting it A consumer needs to know which earlier output a correction refers to. A timestamp alone may be insufficient if multiple measurements or revisions share that time. ``` ### What a Strong Answer Covers - A clear distinction between source-supplied ordering and the unresolved alignment, duplicate, and missing-value semantics. - A merge or keyed-state approach consistent with a declared interpretation of the observations. - A distinction between provisional output and output considered complete under a chosen lateness policy. - Stable result identities, revision or version information, and an idempotent way to replace or adjust earlier outputs. - Recovery and replay behavior that does not double-apply corrections or let an older result overwrite a newer one. - Memory or retention implications of waiting for missing counterparts and accepting late corrections. ### Follow-up Questions 1. How would a repeated event delivery differ from a genuinely revised measurement at the same timestamp? 2. What should happen when an event arrives after the system's chosen reconciliation-retention window? 3. If a correction reaches a consumer before the corresponding initial result, how should that consumer converge to the right value?