Does the NATS Jetstream guarantee delivery order?Please read the below scenario

[kharabela]

Ordering Assurance
Messages from a single publisher are delivered in the order they’re created to the subscriber. For multiple publishers, messages are out of order for different subscribers, and there’s no guarantee that messages will be delivered in the order they were published.

While out-of-order message delivery can be limiting in some use cases that require strict message ordering, it offers high performance and scalability benefits. For instance, you need message ordering to build control systems in a factory setting, but whether temperature readings from different sensors are delivered in a particular order is less critical.

For temperature, you need the latest measurement to be delivered on time, but it’s not important that an old reading is received last. By including timestamps in the message so that older timestamps can just be discarded, you can mitigate the ordering challenge in cases where it isn’t needed.

[jnmoyne]

Messages are recorded in the stream strictly in the order they are published and then received by the nats-server which is the leader for that stream at the time the message is published (and time stamped with the clock of that server, and that timestamp is in the message's JetStream metadata). They are then delivered to the consumers in the order the are recorded in the stream.

If you need messages to be recorded in the stream in a particular order (for a subject) the publishing application simply needs to do a GetLastMsgForSubject() and then compare that last message with the one they want to publish for ordering and either publish it (if there is no message in the stream for that subject or if the last message is 'older') or not. You can even control potential race conditions by specifying in a publish option what you expect the current last sequence number for the subject to be.