Notes that sync across your devices

The brief

Build a notebook that works on a phone and laptop, including a month offline. Edits should reach connected foreground devices in under a second, concurrent work must not disappear, and the server should not need plaintext notes. Push wakes devices; durable sync must work when push does not.

Think of a private offline notebook like Standard Notes.

Users, scale and requirements

Who uses it

1 million people with about 3 devices each (approx.)

Audience in plain numbers

1,000,000 users or devices

Normal peak

≈ 3,000 requests per second

Request mix

Sync change: 60%; Read: 35%; Notification: 5%

Speed for 99 of 100 requests

Sync change: ≈ 900 ms; Read: ≈ 900 ms

Successful requests

99.8%

Data safety

No acknowledged write may be lost.

Monthly budget

≈ $4,400

Data at rest

≈ 2 TB

Where users are

North America: 100%

Home region

North America

Waiting deadlines

Sync change: 900 seconds; Read: 900 seconds; Notification: 900 seconds

Minimum retained history

90 days on authoritative stores

Fresh reads

People must see their own changes. At most 0.1% of reads may be stale in the model.

Required proofs

Managed encryption keys; Audit trail

≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.

• Each sync operation carries about 1 KB. A notebook has 10,000 notes of about 2 KB each; one pull finds 50 changed notes. Keep tombstones for 90 days and support devices offline for 30 days (approx.).
• Under-a-second is a foreground connected-device goal. Background push and offline devices have eventual delivery. The scored notify path measures sender acceptance, not device receipt.
• The graph carries encrypted operations and small reads. It does not implement offline storage, conflict resolution, cursors, end-to-end encryption, recovery or tombstones. A traffic pass does not prove these properties.
• KMS and audit nodes protect server metadata and record content-free access/deletion receipts. They are not the end-to-end content key service.
• The 900 ms target measures one request. Subsecond propagation needs an end-to-end budget across commit, change notification, pull and local application; a traffic pass does not verify it.
• Sources emit only their assigned request types. The source rates below reproduce the aggregate workload; protocol guarantees still require the separate design checkpoint.
• Scored data retention: at least 90 days on active authoritative stores. Copies used only for search or reports can be rebuilt. Local device history and rollup policies still require the separate protocol check.
• Notification speed measures provider acceptance. Device receipt is outside this traffic model; check expiry, provider outcome and retries in the correctness trace before claiming delivery guarantees.

Questions that shape the design

What does saved mean offline?

The note edit and device outbox operation are committed locally before the screen says saved on this device. Synced means the server durably accepted the operation. Losing the device before sync remains a real data-loss boundary.

What happens to conflicting edits?

Use stable operation ids and base versions. Preserve concurrent whole-note edits as conflict versions in the first release. Do not silently pick by wall time. A text CRDT is a possible later choice with a tested merge policy.

How long can a device be away?

Support 30 days. Keep deletion history for 90 days with a documented margin. Older cursors require snapshot rebase and version-checked replay of preserved local edits. A stale full upload must not resurrect a deletion.

Which privacy features are required?

Encrypt note bodies on devices. The server stores ciphertext and minimal routing metadata. Search is local. Device enrollment, revocation and an explicit recovery key are part of the design. Server KMS protects metadata only; it does not hold note decryption keys.

The traffic day

Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

1. 11:00 · Zone outage

   An availability zone loses power or network access.

   Duration: ≈ 3,600 seconds.

2. 16:00 · Synchronized rush

   Many callers send requests together instead of spreading them over time.

   Traffic for Sync change reaches 2 times the scheduled load; rises over 10 seconds, holds for 60 seconds and eases over 300 seconds. Other request types keep their scheduled load.

3. 20:00 · Retry storm

   A brief failure causes clients to retry, adding load while the service recovers.

   Failed calls: 90%. Duration: ≈ 30 seconds. Duration: ≈ 1,200 seconds.

What a strong design has to handle

• What must be committed locally before a network request, and what does a sync cursor acknowledge?
• Merge encrypted offline edits and propagate deletion without relying on push.
• Conflict copies are easier to explain and test than arbitrary text merging, but users must resolve them. A CRDT can reduce manual conflicts at the cost of metadata, compaction rules and editor-specific semantics.
• End-to-end encryption moves search and key handling to devices. Recovery needs an authorized device or a recovery secret; password reset alone cannot reconstruct content keys. Metadata still leaks timing and sizes.

Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.

Concepts to practise

• Syncing across devices
• Ordering and time
• Privacy by design
• What consistent really means
• Work across services