Skip to content

CONCEPT Cited by 1 source

Authoritative vs fast notification

Definition

A two-tier correctness posture for real-time applications in which one channel carries durable, authoritative state changes (typically a transactional database commit) and a separate, best-effort channel carries low-latency notifications (typically WebSocket / SSE / pub-sub) that state has changed. Clients treat the notification channel as hints — fast but lossy — and the authoritative channel as ground truth — slower but correct.

The explicit design rule comes from the 2026-02-19 PlanetScale × Cloudflare Hyperdrive demo post (Source: sources/2026-04-21-planetscale-faster-planetscale-postgres-connections-with-cloudflare-hyperdrive):

"One useful principle in real-time apps is to decide what is authoritative and what is just fast. In this architecture, Postgres is the source of truth and WebSockets are the low-latency notification layer. That distinction matters. WebSocket messages can be delayed or dropped due to normal network behavior, but database writes are still durable. So the contract for clients should be: 'updates are immediate most of the time, and eventually correct all of the time.'"

The client contract

The load-bearing formulation is "immediate most of the time, and eventually correct all of the time." Two guarantees at two different time horizons:

  • Immediate (best-effort): the fast-notification channel pushes a change within milliseconds of the write completing. No delivery guarantee — messages can be delayed, dropped, or reordered by normal network behaviour.
  • Eventually correct (durable): the authoritative store reflects the committed state with full ACID guarantees; any client that asks (poll, re-fetch, reconnect with cursor) will see the correct state.

The client-side implication: never act on a notification without validating against the authoritative source when correctness matters. The PlanetScale post's companion stale-quote rejection example is the concrete form — the client-observed price from a WebSocket push is submitted back with the transaction, and the DB rejects the transaction if that price is no longer valid at write time.

Why the separation matters

Single-channel designs force a choice between latency and durability:

  • Durable-only (e.g. client polls the DB): every update costs a full DB round-trip and the fastest update cadence is the polling interval. Correct but slow.
  • Notification-only (e.g. WebSocket IS the authority): updates are fast, but dropped messages silently corrupt client state. Fast but wrong under realistic network conditions.

Splitting the two channels gets both: the DB commit is the "are we in agreement?" anchor; the notification layer is the "tell me quickly when we move" accelerator. Client correctness comes from refusing to let the fast channel override the authoritative one.

Canonical production shape

From the 2026-04-21 PlanetScale post:

  1. Client submits a write (with current observed state, e.g. price + version).
  2. Worker sends transaction to Postgres via Hyperdrive pooled connection.
  3. DB validates against its current state; rejects the write if the client's observation is stale.
  4. On success, Worker "pings the Durable Object via the WebSocket connection to fan out that update to all other connected browsers" — patterns/single-region-do-fanout-from-distributed-writers.
  5. Other clients receive the WebSocket push and update UI immediately.
  6. If the WebSocket push is dropped, the state is still correct on the next DB read / poll / reconnect.

Production hardening not yet implemented

The PlanetScale demo post explicitly defers three hardening moves that would strengthen the "eventually correct" guarantee:

  • Replay on reconnect: "A reconnecting client could ask for events since a known cursor. We skipped this for simplicity." Shifts eventual-correctness from "next poll" to "next reconnect".
  • Queue-backed fanout: "A queue can improve durability and retries between write completion and broadcast. Cloudflare has a Queueing service, too!" Adds durability between the write-committed and notification-sent events.
  • Polling reconciliation: "Periodic polling can catch any missed updates from WebSockets." Bounds eventual-correctness by a polling interval.

All three are upgrades to the notification channel, not replacements for the authoritative-vs-fast split — the DB remains the source of truth under every hardening layer.

Adjacencies

  • Not the same as concepts/eventual-consistency — that is about replica convergence in a distributed store. Authoritative-vs-fast is about the communication channel between a single authoritative store and many notified consumers.
  • Complements concepts/single-writer-assumption — the fast channel is often a single-writer coordinator (e.g. a Durable Object fanning out to WebSocket subscribers), while the authoritative channel is the durable transactional DB under it.
  • Generalises the CDC-vs-queue reasoning: a CDC stream off the DB binlog IS the notification channel in that shape; Postgres logical-replication → Kafka → subscribers is structurally identical.

Seen in

Last updated · 347 distilled / 1,201 read