Built right

130 ms. Push, not poll.

The other parent adds soccer practice. Your phone gets a soft chime and updates the calendar — before they've put their phone down. Cozi polls every 5 minutes. We push. There's a difference.

Real-time calendar updating across devices
The problem

Polling is a confession.

Most family calendars refetch the family data every few minutes. That's a polling architecture. It means stale views, wasted battery, and exactly the kind of "Wait, did you see I added that?" misalignment that destroys trust in the tool.

We measured Cozi at ~5-minute polling intervals. FamilyWall is similar. We replaced the whole thing with Server-Sent Events on day one.

"If the calendar isn't trustworthy in real time, we go back to text-message coordination." — A devastating user-research quote.
How it works

SSE, with a polling safety net.

Every device opens an EventSource to GET /api/families/{code}/stream when it boots. The server pushes a tiny revision event the moment any mutation lands; the client refetches the family doc in the background. No polling, no battery drain, no stale state.

Idle sessions make zero polling GETs (vs the old design's 720/hour). Live-update latency dropped from "up to 5 seconds" to ~130ms in our measured tests. There's still a 30-second polling fallback for corporate networks that block SSE — defense in depth.

  • Heartbeats every 25s keep the connection alive through reverse proxies
  • Exponential reconnect (1.5s → 30s cap) for transient outages
  • Singleton hub with per-family async queues — slow consumers drop oldest events, never block
  • nginx X-Accel-Buffering: no so the ingress proxy doesn't sit on each event
Today screen with live updates
Per-device auth

The 6-char family code is not a credential.

Most family apps treat the join code as both an identifier AND a credential — knowing it grants access. That's the same security model as a hotel WiFi password. We rebuilt it.

The 6-char family code (e.g., DEMO99) is now just an identifier. To join, you scan a 60-second pairing code generated by an existing device (Netflix-/Hulu-/Apple-TV style). The new device gets its own per-device bearer token. The token is stored as a peppered SHA-256 hash server-side — even a database breach doesn't leak tokens.

  • 60-second pairing codes single-use, no replay
  • Per-device revocation — lose your phone, kill just that device, the rest of the family stays signed in
  • Encrypted OAuth refresh tokens at rest (Fernet) — Google Calendar tokens are never readable from the DB
  • Privacy-safe audit log — every write is logged with hashed IPs/UAs (peppered SHA-256) so forensics are possible but a stolen audit-log dump is useless
  • Redis-backed rate limiting across replicas so the limits are real, not per-pod theater
The numbers

Measured, not marketed.

~130 ms
Cross-device update latency
0
Polling GETs in an idle session
23/23
Security tests passing in CI

Trustworthy in real time. Or it's not a calendar.

Our Life is built on Server-Sent Events, per-device bearer tokens, encrypted OAuth, and a privacy-safe audit log. Most family calendars don't even have HTTPS to the family doc figured out.

Get the launch invite