JetStream Timestamp May Represent Acceptance Not Storage Time Under Load

Answer

The JetStream Timestamp field always records the instant the leader replica accepts a Publish request, not the moment the message is durably written to storage.

Why the timestamp can precede storage completion

Under heavy load or during network partitions the underlying storage backend (file store with fsync delays or asynchronous memory‑store flush) may take additional time to persist the message. Because the timestamp is generated with time.Now().UTC() before the write begins, the observed offset equals the storage latency.

Maximum observable offset

The offset is bounded by the worst‑case storage latency of your configured backend:

• File store: limited by the fsync interval and disk write latency (typically a few milliseconds to tens of milliseconds under load, but can spike to seconds if the disk stalls).
• Memory store: limited by the asynchronous flush interval (default 0 ms, but if you enable StoreInterval it can be up to that interval).

Without knowing your storage backend and fsync/flush settings we cannot give a precise numeric bound.

Distinguishing acceptance from storage time

NATS does not expose a separate “storage‑completed” timestamp in message metadata or via a dedicated API. You can infer the gap by:

1. Enabling server debugging (nats server -debug) which logs both accept and store events for each message.
2. Comparing the producer’s timestamp with the consumer’s receipt time while measuring end‑to‑end latency.
3. Inspecting JetStream monitoring metrics such as js_stream_msg_store (messages successfully stored) versus js_stream_msg_accepted (messages accepted) – the difference in rates indicates back‑pressure.

To give a concrete recommendation, please confirm which JetStream storage backend (file or memory) and any fsync/flush configuration you are using.