Three different questions
A sequence number, event timestamp and receive timestamp describe different properties. A source sequence may specify the order in a particular channel. An event timestamp records a time assigned by the source. A receive timestamp records when a consumer observed the message. Their meanings must come from the feed specification.
Define the scope of ordering
Sequence numbers can be per connection, partition, channel or instrument. A larger number is not necessarily later across different scopes. Document the scope before using a sequence number to detect gaps or reconstruct state.
Do not repair semantics by sorting
Sorting by receive time can change the order of source events after transport delay or replay. Sorting by event time can also be inappropriate when timestamps share a resolution or come from different clocks. A deterministic sort is not automatically a valid reconstruction.
A three-message witness
Consider SET messages for one object: sequence 1 sets quantity to 10, sequence 2 sets it to 4, and sequence 3 sets it to 7. The contract specifies one sequence scope and replacement semantics: every SET overwrites the previous quantity.
Source-order replay ends at 7. Receive-order replay 1, 3, 2 ends at 4. Both programs can be deterministic; only the first follows this contract. A different protocol may require different handling, so this is not a general rule to sort all feeds by a field called sequence.
Run the public experimentA reproducible experiment
The public Aurora Lab example includes a three-message synthetic stream with one delayed update. Compare source-sequence replay with receive-order replay. The different final values illustrate why reconstruction needs a stated ordering contract, rather than a guessed one.
Document the contract
Record timestamp units, clock domain, sequence scope, duplicate handling and the recovery procedure. Retain original message fields alongside any normalised representation. The goal of this example is data integrity, not price prediction or trade execution.
Recovery is part of the model
A real handler needs explicit responses to duplicates, gaps and session resets. Depending on the protocol, it may buffer messages, request recovery, load a snapshot or mark the state unavailable. Re-sorting whatever arrived is not a general recovery procedure.
Record when the state becomes trustworthy again and what evidence restored it. Preserve raw fields alongside normalised records. A downstream consumer should be able to distinguish an incomplete state from a valid one without inspecting the entire event history.