PATTERN Cited by 1 source
Durable client outbox with settled overlay¶
Persist a user operation locally, optimistically overlay its result in the UI, and retain that overlay after the backend acknowledges the write until an authoritative live read confirms it. This prevents the familiar read-after-write flicker in eventually consistent systems: the write succeeds, the immediate read remains stale, and the UI otherwise appears to reverse the action.
Flow¶
User action
→ persist {id, payload, pending} in local outbox
→ apply optimistic overlay
→ deliver when readiness allows
→ mark operation settled on backend acknowledgement
→ retain overlay
→ poll/revalidate authoritative read
→ if read reflects operation: remove outbox item and overlay
→ if terminal failure: remove item and roll back overlay
When to use it¶
Use this when client actions are important enough to preserve across short offline or convergence windows, and when the read model can lag behind an accepted write. It is especially useful for relationship-style mutations (save, RSVP, add-to-schedule, subscription) where a temporary visual reversal is more harmful than a bounded local overlay.
It requires stable operation IDs, server-side idempotency, a semantic liveStateReflects(operation, liveState) check, and an explicit terminal-error path. It should not mask permanent authorization failure or silently retry indefinitely.
Seen in¶
- sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack — Atlassian's Unleash PWA implements
pending → settled → confirmedclient operations against Jira. A settled operation's overlay survives until a live read reflects it, then both the operation and overlay are removed.