Message Ordering
Build predictable live updates with ordered streams, message identity, and application versions.
Celeris preserves the order of messages within a segment from the same origin node, including when those messages travel across regions. The JavaScript SDK calls your message listeners in the order messages arrive.
For a stream of chat messages, order updates, or game events, this lets your application process a sender's updates in sequence while Celeris handles routing to connected subscribers.
How ordering works
An origin node is the Celeris server that first accepts a published message. A publisher's active channel connection sends its messages through that node.
Suppose your backend publishes these updates in sequence to one segment over the same connection:
Order received -> Preparing -> Ready for collection
Celeris preserves that sequence for the delivered messages, whether a subscriber is connected locally or in another region. You do not need to sort that single-origin stream on the client. The same ordering applies to retained messages replayed from that origin.
| Scope | Ordering behavior |
|---|---|
| One segment, one origin node | Messages retain their order, including across regions |
| One segment, several origin nodes | Each origin's stream retains its order; messages from different origins can interleave |
| Separate segments | Each is its own stream; use one segment when related events need a shared ordering scope |
This applies to default as well as named segments. Ordering describes the sequence of delivered messages; recovery of messages sent during a disconnection is covered in Reconnection and Recovery.
The SDK invokes listeners synchronously. If a listener starts asynchronous work, that work can finish out of order. Apply simple UI updates directly in the listener, or serialize asynchronous processing when completion order matters.
Coordinate updates from multiple publishers
Independent publishers can update the same segment concurrently. If they connect through different origin nodes, Celeris preserves each origin's sequence without imposing a single global order between them.
For example, these are two valid ways to receive concurrent streams:
Origin A: A1 -> A2
Origin B: B1 -> B2
Subscriber 1: A1, B1, A2, B2
Subscriber 2: B1, A1, B2, A2
Both subscribers receive A1 before A2 and B1 before B2. Their interleaving can differ.
For updates to shared business state, include a version assigned by the backend that owns that state:
{
"orderId": "order-42",
"version": 18,
"status": "ready"
}
Store the latest version alongside the displayed order. Apply a newer complete snapshot and ignore an older one. If events contain incremental changes and a version is missing, fetch the current state from your API before continuing. Your database or owning service assigns these versions; they are application data, not Celeris message metadata.
This keeps the responsibilities clear: Celeris delivers the live stream, and your application decides which update represents the current business state.
Identify messages consistently
Every delivered message includes a messageId. Supply your own ID when publishing to correlate an event with your application, or let Celeris assign one.
The JavaScript SDK uses these IDs to filter duplicates within its most recent 1,024 IDs per channel. Use one ID per logical message; different updates should have different IDs.
A message ID identifies an event, while an application version describes its place in your business state. Treat them separately: IDs are not sequence numbers or replay cursors. For durable operations such as recording a payment, keep idempotency in your own backend as well.
Continue after a disconnection
After an established connection drops, the SDK automatically attempts to reconnect, obtains fresh credentials, and restores held subscriptions. Existing listeners remain registered. When your server authorizes replay, Celeris can deliver retained messages to help the application catch up.
For a live dashboard, use the recovery event to refresh its current state from your API, then continue applying live updates. This combines recent-message replay with an authoritative snapshot when the outage extends beyond retained history. Replay is bounded, so applications should account for possible gaps and duplicates.
See Reconnection and Recovery for the recovery lifecycle and replay policy. For the distinction between local publish completion and remote delivery, see Publishing messages.
Next: Reconnection and Recovery.