Realm Mobile Client and Sync Server: Measuring Sync Latency Across Change Notification Boundaries

We are evaluating sync latency between the Realm mobile client and Sync Server in current SDKs before optimization. The goal is to baseline how long a batch write takes to propagate and become observable through change notifications. Realm's change notification mechanism relies on JSON patch semantics, delivering diffs only when property values change, creating uncertainty about whether a client that re-queries after a batch write observes every intermediate state or only the final consolidated diff.

Additional constraints complicate measurement. The default sync endpoint enforces a 60-second session timeout, and prolonged offline periods require explicit re-authentication, adding variable delay. Cross-platform conflict resolution uses last-writer-wins timestamps, so concurrent edits can silently overwrite each other, complicating latency attribution. Realm Studio's timeline view and network logs are available, but it is unclear which signals correspond to server-side sync versus client-side notification batching.

We need to clarify the measurement boundary. Does the change notification mechanism guarantee that all property-level diffs from a batch write are delivered before the session timeout, or can a post-batch re-query miss intermediate states? When profiling sync latency across iOS and Android, should the session timeout and re-authentication delay be included in the latency budget, or treated as a separate metric? Is there a documented way to distinguish network-induced sync latency from local change-notification batching in Realm Studio's timeline view?