Index
A sensor may send a reading after a newer one, particularly following connection loss. Sorting solely by arrival makes a process appear to reverse or hides intermediate events.
The design to commission
Retain measurement time, receipt time and device identity. Define how late readings affect computed aggregates and what window permits recomputation. The decision depends on use: historical analysis may incorporate corrections while an operational alert needs to disclose late arrival. Check device-clock reliability and restart handling. Event identifiers support deduplication; where absent, alternative rules need documentation and testing. Do not promise real-time operation without assessing connectivity and capture frequency. Scope should cover recovery after interruptions, separation of reading quality from transport quality, and inspection of incomplete periods. A technically successful transfer is insufficient if the timestamp meaning has changed. Ask who approves recomputation and how users can distinguish provisional results from values that already include all expected readings for the period.
Supplier criteria
- Keep measured time separate from receipt time.
- Define recomputation windows for each indicator use.
- Handle duplicates and inconsistent clocks without inventing readings.
Acceptance with an exception
In a hypothetical scenario, a disconnected sensor transmits old readings alongside current ones. History must preserve measured order and reporting should identify delay rather than present old events as new instantaneous observations.
Reference for assessing scope
PostgreSQL constraint documentation
Prepare your project with Quantum9
Share an anonymized disconnect-and-return sequence with Quantum9. Discovery defines ordering, deduplication and realistic limits for the update frequency your operation actually needs.