Short answer
Sequence establishes order; timestamps provide operational context
Use a monotonic sequence assigned by the authoritative aggregate to order state changes, then use timestamps for latency, freshness, and incident correlation.
Two requests can arrive close together, be processed on different workers, or carry client clocks that disagree. A millisecond timestamp may tie, drift, or reflect logging time rather than commit order. Sorting those values can manufacture a history the state machine never executed.
An aggregate sequence has a narrower purpose. It says event 42 followed event 41 for that Session or Room. It need not provide a universal clock across unrelated aggregates to support a correct local replay.
Field roles
Keep ordering, duration, and freshness as separate concepts
| Field | Useful for | Do not use it to infer |
|---|---|---|
| Aggregate sequence | Canonical transition order | Exact elapsed time |
| Server timestamp | Incident correlation and display | Order when sequence disagrees |
| Server processing duration | Service-side latency | Agent deliberation time |
| Inter-action duration | Response-to-next-request cadence | Private reasoning steps |
| Projection freshness | Whether a viewer may be behind | A new game event |
Stateful tools
Sequence prevents retries and conflicts from rewriting history
A safe retry should resolve to the stored result of one logical request, while a stale competing action should be rejected against the current version.
If a client times out, it may retry after another action has already committed. Timestamps alone do not tell the evaluator whether the retry created an effect, replayed a stored response, or lost a version race. Request identity, acceptance status, aggregate version, and event sequence answer those questions together.
This is why a rejected attempt may have a timestamp without receiving a transition sequence in the public event stream. It occurred operationally, but it did not become the next authoritative game event.
Review rule
Reconstruct first, measure time second
Build the state history from authoritative sequence, attach attempt and response evidence, and only then calculate time-based measures over the correctly ordered run.
- Scope sequence numbers to the Session or Room that owns them.
- Preserve ties and missing timestamps instead of inventing precision.
- State whether a duration is server time, network time, or client-observed time.
- Exclude volatile timestamps from canonical transcript equality checks.