Immediate Server Sync vs Optimistic Local Updates: Which Keeps Notion Data Freshest Across Devices?
0 reputation · 10 Jan 2020, 21:00 UTC
0 reputation · 10 Jan 2020, 21:00 UTC
Determine how Notion’s offline editing strategy affects data freshness when multiple devices edit the same page. The focus is on the trade‑off between immediately pushing changes to the server versus applying updates locally and deferring cache invalidation until a sync cycle completes.
Notion stores a local cache (IndexedDB on the web, SQLite on mobile/desktop) to enable offline access. When a user edits a page offline, the client applies the change locally for responsiveness but does not invalidate cached data from other devices until a sync cycle occurs. If the client remains offline for an extended period, it may serve stale content until reconnection triggers a full sync. Users have reported that content edited on a different device while the first device is offline can appear outdated until the next sync, indicating that cache invalidation is deferred rather than immediate.
35275 reputation · 11 Jan 2020, 03:53 UTC
Neither strategy is a switch you can flip, and the framing hides the real lever. Notion-style clients apply your edit to the local replica first and queue the upload, so the device you are typing on always looks current. Cross-device freshness is therefore decided by how quickly remote changes arrive from the server, not by whether the write path waits for a round-trip. If you want another device to show a change sooner, the write path is the wrong place to look.
A client that blocked the UI on a server round-trip before rendering an edit would be unusable offline and sluggish online. That is why local-first clients converge on the same shape: optimistic local apply, then push. The genuine design choice is between optimistic local apply with prompt push/pull and a hypothetical blocking write, and the second option is not one a production note-taking client ships.
The consequence is a distinction worth keeping straight: apparent freshness (your screen reflects your own pending edit) is not the same as convergence (all devices agree). Optimistic updates can produce a "false fresh" state where your device shows a value the server has not accepted.
Observable and reasonably safe to state: edits appear instantly regardless of connectivity; a local cache persists them across app restarts and hard reloads; a device that stays offline shows stale content from other devices until it reconnects.
Inferred, not confirmed: the specific transport (persistent connection vs. long-poll) and the exact invalidation timing. Notion's sync internals are not publicly documented, so treat any claim about the mechanism as inference from behavior and from general local-first architecture. There is no known user-facing preference that forces immediate invalidation on detecting a remote update; freshness is governed by connection state, subscription scope, and sync scheduling.
| Symptom | Likely cause |
|---|---|
| Editing device always current | Local apply is immediate by design |
| Second device lags while both online | Delivery of the remote change stream, not the write |
| Second device stale for hours | It was offline; staleness is guaranteed until reconnect |
| Change vanished after reload | Local-only state never reached the server |
| Different value than expected after reconnect | Merge/conflict resolution, a separate concern from freshness |
Note that "cache invalidation" here means the client's local replica of page data, not HTTP or CDN caching. Conflating the two leads to wrong conclusions. Permission changes and client version skew can also mimic staleness.
These are observational procedures, not benchmarks; run them on your own workspace rather than trusting a general figure.
Does the lagging device stay connected while it lags? If it is online and still stale, the problem is delivery or subscription scope and worth investigating. If it was offline, the behavior is expected and no setting will fix it. Answer that and the rest follows.
Choose optimistic local updates — there is no real competitor. Then manage expectations: treat the editing device as authoritative only for its own pending edits, and treat reconnection as the moment convergence begins, not the moment it is guaranteed.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.