PATTERN Cited by 1 source
Access check before idempotent provisioning¶
Check whether a returning identity already has the required access before invoking an idempotent provisioning workflow. If access exists, continue on the fast path; if it does not, provision and then verify access again. Idempotency protects correctness, but it does not make an unnecessary synchronous provisioning call free on every session.
Flow¶
fetch identity → check access
├─ access exists → load application
└─ access missing → provision → re-check access → load application
The final verification is important because provisioning and permission propagation can be eventually consistent. Combine this pattern with an explicit convergence state, rather than assuming the provisioning API's success response means every downstream read is immediately ready.
Seen in¶
- sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack — the Unleash PWA originally serialized identity fetch, user provisioning, group check, user setup, and application data loading. Provisioning was only necessary on first use; checking access first allowed returning users to skip it, reducing their load time by about five seconds.