Health readings from a wearable

The brief

A wearable records health readings even when its phone or cloud service is unavailable. Keep raw readings on the device when possible and upload only consented summaries in sparse batches. The system must not lose locally saved readings during a supported outage, and deleting an account must have a verifiable end-to-end workflow.

Think of private health summaries from a wrist device.

Users, scale and requirements

Who uses it

100,000 wearables with sparse opt-in uploads (approx.)

Audience in plain numbers

100,000 users or devices

Normal peak

≈ 500 requests per second

Request mix

Telemetry batch: 90%; Read: 8%; Notification: 2%

Speed for 99 of 100 requests

Read: ≈ 1,500 ms

Successful requests

99.9%

Data safety

No acknowledged write may be lost.

Monthly budget

≈ $2,100

Data at rest

≈ 0.0365 TB

Where users are

North America: 100%

Home region

North America

Waiting deadlines

Telemetry batch: 3,600 seconds; Read: 900 seconds; Notification: 900 seconds

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.

• Local raw readings are 16 B each at one reading per second. Reserve at least 30 days of local raw capacity for the supported 14-day outage. Each of 100,000 opted-in devices uploads at most one 1 KB summary per day; raw readings remain local (approx.).
• Cloud peak is a reconnect burst. Use the peak and mix to separate summary ingestion, account reads and wake requests. The daily curve is a conservative capacity drill, separate from the sparse average billing forecast.
• The scored no-loss target concerns acknowledged cloud summaries. The device log, fourteen-day outage reserve, consent, encryption keys and proof of deletion are worked protocol obligations.
• The sender target concerns push acceptance only. No cloud availability percentage is a guarantee of medical safety or survival of a destroyed device.
• Sources emit only their assigned request types. The source rates below reproduce the aggregate workload; protocol guarantees still require the separate design checkpoint.
• 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

Is this an emergency alert service?

No. It is a retrospective personal dashboard. Local trends remain available offline; the cloud must not be presented as a safety-critical alarm path. A medical alarm would require different guarantees.

What is stored locally and for how long?

Assume one 16-byte reading each second, with a durable encrypted local log. Reserve at least 30 days of raw capacity, including overhead and a safety margin. A 14-day phone or cloud outage must not lose readings already durably saved, provided the device remains intact and has power.

What leaves the device?

Only an opt-in daily encrypted 1 KB summary by default, plus explicit user-selected exports. Derive the summary locally. The service has routing metadata but not health-content keys. No raw content in analytics, logs or push payloads.

What if there is no space or a device is lost?

Never silently claim a saved reading when the log is full or not durable. Warn before the supported reserve is exhausted and state the retention policy. Device destruction before an authorized backup is outside the no-loss promise. Recovery and revocation need an explicit key policy.

The traffic day

Traffic concentrated in working hours. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

1. 08: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.

2. 12:00 · Zone outage

   An availability zone loses power or network access.

   Duration: ≈ 3,600 seconds.

3. 18:00 · Synchronized rush

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

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

What a strong design has to handle

• Separate local capture, phone relay and cloud acceptance. Which promise applies while the radio is off?
• Preserve local readings offline and verify consented sync and deletion.
• Thirty days of one 16-byte sample/s is about 41.5 MB payload. Reserve extra for authenticated-encryption tags, indexes, crash-safe metadata and compaction. Do not confuse payload with safe device capacity.
• A saved local reading is protected against the stated software/network outage, not device destruction, power loss before flush or an unbounded disconnection. Define flush semantics and a visible low-space response.

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

• Privacy by design
• Syncing across devices
• Inside a storage engine
• Ordering and time
• SLOs and error budgets