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 recipient 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. For another protocol, the reconstruction order should follow that source’s specified semantics.
Run the public experimentCheck the reconstruction
Replay the same messages in both modes and inspect the event-by-event trace. Check which update is applied last, the quantity after each step and the expected final state. Resetting the experiment keeps the input fixed, so the ordering rule is the only condition changed.
Document the contract
Record timestamp units, clock domain, sequence scope, duplicate handling and the recovery procedure. Retain original message fields alongside any normalised representation. These records establish the data contract used to reconstruct and validate state.
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.