Connection-Local Sequence
What is a Connection-Local Sequence?
A connection-local sequence is a sequence number that is valid only within the lifetime and context of a specific data connection, such as a WebSocket session. It helps consumers apply incremental market data messages in the order they were sent on that connection, but it should not be treated as a permanent, exchange-wide, or globally unique identifier.
In order book reconstruction, connection-local sequencing is useful for detecting gaps, ordering deltas, and deciding when a stream must be resynchronized from a fresh snapshot. Its meaning depends on the provider’s protocol and the connection that produced the message.
How Connection-Local Sequences Work
A market data provider may attach a sequence value to each snapshot, delta, or lifecycle event. While a connection remains active, clients can compare consecutive sequence values to confirm that updates are being processed in order.
If a sequence jumps unexpectedly, repeats in a way that is not idempotent, or arrives after a reconnect with a reset numbering scheme, the consumer should follow the provider’s recovery rules. This often means discarding local state, requesting or waiting for a new snapshot, and replaying subsequent incremental updates from a known-good point.
Because the sequence is connection-local, the same numeric value can appear on another connection or after a reconnect without referring to the same event. It is a transport-ordering aid, not a durable order ID, trade ID, or global event ID.
Why It Matters for Order Book Reconstruction
Order book reconstruction depends on applying updates in the correct order. When data arrives over streaming protocols, a connection-local sequence gives the consumer a way to verify continuity inside that stream.
For Level 3 and Level 4 data, sequence handling is especially important because updates may refer to individual orders, order states, or conditional order structures. Applying those messages out of order can create invalid local state, such as missing orders, stale quantities, duplicate lifecycle events, or crossed books.
A robust reconstruction engine should store the last accepted sequence for each connection, reject or recover from gaps, and avoid assuming that a sequence number has meaning outside the active stream.
Common Implementation Pitfalls
A common mistake is treating a connection-local sequence as a global exchange sequence. This can cause incorrect joins across connections, misleading replay logic, or false assumptions about event uniqueness.
Another pitfall is continuing to apply deltas after a disconnect or suspected message gap. If continuity cannot be proven, the safest approach is usually to resynchronize state from a snapshot rather than trying to patch the book from incomplete data.
Consumers should also distinguish sequence numbers from identifiers such as order IDs, trade IDs, symbols, or timestamps. Each field serves a different purpose in market data processing.
Connection-Local Sequence and CoinAPI
CoinAPI market data streams can include sequencing, timestamps, exchange identifiers, symbols, and message types that help developers process real-time updates consistently. When building an order book reconstruction pipeline, developers should interpret each sequence field according to the exchange and feed semantics rather than assuming one universal meaning.
For advanced feeds such as order-by-order or L4 data, a reconstruction engine should combine sequence checks with snapshots, lifecycle event handling, idempotent update logic, and validation rules. This helps maintain a correct local view of executable market depth even when network sessions reconnect or restart.