ATLASSIAN 2026-08-07

Building a real-time PWA on Atlassian's own stack¶

Summary¶

For the 2026 Atlassian Unleash event, Atlassian built a React/TypeScript progressive web app (PWA) for schedule management, session recordings, rewards, push notifications, and an AI event guide. Rather than introduce an event-specific database and administration service, the team made Jira Cloud the workflow-shaped system of record, used Jira Automation as the scheduling/control plane, and placed a thin stateless service only where browser calls needed elevated privileges or traffic smoothing. The important engineering work was at the consistency and user-experience boundary: provisioned users converge asynchronously, writes are persisted in a local durable outbox and retained as an optimistic “settled overlay” until a live Jira read confirms them, and the app serves safe local data before background revalidation. The same discipline produced a large performance recovery: <1 s time to first useful content, from an approximately 12 s loader. (Source: sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack)

Key takeaways¶

Use a workflow-native system of record when the domain is workflow-shaped. Jira issues, fields, roles, automation rules, and audit history represented sessions, speakers, registrations, XP events, announcements, subscriptions, and leaderboard rows without a custom admin system. Atlassian deliberately accepted that this data was not deeply relational, so the configuration and governance strengths of Jira outweighed a bespoke data model. (Source: sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack)
Make eventual readiness an explicit state machine. New account provisioning and permission propagation do not become visible atomically. The client distinguishes a converging state, where it can render safe cached data and capture user intent, from a ready state, where live reads are authoritative. This prevents first-login consistency lag from becoming an empty screen or a misleading terminal error. (Source: sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack)
A successful write is not sufficient evidence that the read model has caught up. The PWA saves an operation locally before contacting the backend, performs an optimistic update, changes it to settled after the backend accepts it, and removes that overlay only when a live Jira read reflects the operation. The extra settled state avoids the UI appearing to undo an action during read-after-write lag. (Source: sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack)
Treat leaderboard totals as a repairable projection, not the truth. XP events are the write model. Jira Automation computes leaderboard rows through near-real-time updates, periodic incremental recomputation, and full rebuilds. New reward rules can then be configured, and an incorrect aggregate can be repaired from source events. (Source: sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack)
Completed-response caching does not deduplicate concurrent React startup reads. Several components mounted together and requested the same data before any response had arrived. Sharing the in-flight promise reduced page-load calls from 24 to 16 and duplicate calls from 8 to 0. This is the client-side, in-process form of request collapsing. (Source: sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack)
Revalidation should follow mutation semantics, not a blanket refresh policy. Adding a session to a personal schedule does not alter the session catalogue. After classifying completed mutations, the application refreshes only data that could have changed; many operations require no follow-up fetch because the optimistic overlay already represents the intended state. Add-to-schedule calls fell from 11 to 5. (Source: sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack)
Stale-while-revalidate is a resilience pattern as well as a performance pattern. Rendering bundled or local data immediately and refreshing it in the background allowed useful content before all authentication and platform API paths were healthy. The same mechanism covers normal startup, permission convergence, and later degraded reads. (Source: sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack)
Make idempotent provisioning conditional. The original startup path provisioned every visitor serially. The revised flow checks access first, provisions only users who lack it, and re-checks afterward. Returning users avoid the provisioning path, cutting roughly five seconds from load time without weakening first-use access safety. (Source: sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack)
Build configuration can dominate front-end performance. An unminified production bundle was approximately 7.7 MB. Correcting the production build reduced it to approximately 1.53 MB (about 80% smaller), demonstrating that transport and build inspection are prerequisites to micro-optimisation. (Source: sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack)

Architecture¶

React/TypeScript PWA on static hosting + global CDN
  │ authenticated calls
  ▼
Atlassian platform edge (routing, session management, API gateway)
  │
  ├── Jira Cloud ── source of truth for event/workflow records
  │     └── Jira Automation ── scheduled recomputation, reminders, workflow transitions
  │
  ├── Thin stateless service ── privileged bot writes, notification signing,
  │                              traffic-spike smoothing; no business state/database
  │
  ├── Rovo + Confluence ── AI event guide
  ├── Loom ── recordings and AI summaries
  └── Bitbucket + Pipelines + Rovo Dev ── live coding challenge delivery

Client consistency path:
user action → local durable outbox → backend accepted → settled overlay
          → live Jira read confirms → remove local operation and overlay

Operational numbers¶

Metric	Before	After	Mechanism
Concurrent users	—	500+	Event PWA production load cited by the post.
Page-load API calls	24	16	Shared in-flight promises.
Duplicate page-load calls	8	0	In-flight request deduplication.
“Add to schedule” API calls	11	5	Mutation-aware sparse revalidation.
Production JavaScript bundle	~7.7 MB	~1.53 MB	Fixed minification configuration (~80% smaller).
Returning-user auth overhead	baseline	~5 s less load time	Check access before idempotent provisioning.
Time to first useful content	~12 s	<1 s	Local/bundled render plus background revalidation.
App adoption	—	110%	Includes attendees beyond the event room.
Attendee download rate	—	80%	32% downloaded before the event.
Features/bugs shipped live	—	8	Rovo Dev → Bitbucket → Pipelines → production loop.

Systems extracted¶

systems/atlassian-unleash-pwa — the named event application and its composition of static PWA, Jira, automation, platform edge, and a thin privileged service.
systems/jira — workflow-shaped system of record, admin surface, and automation control plane.
systems/rovo-chat — event-guide surface grounded in Confluence.
systems/rovo-dev, systems/bitbucket, and systems/bitbucket-pipelines — the live feature-delivery path used during the event.
systems/react — browser component framework used for the static PWA.

Concepts extracted¶

concepts/eventual-consistency — provisioning, permission propagation, and read-after-write visibility lag are explicitly tolerated.
concepts/eventual-readiness — client readiness is modeled as converging versus ready, not a Boolean.
concepts/durable-client-outbox — pending user operations survive locally before the remote write succeeds.
concepts/request-collapsing — promise sharing coalesces identical concurrent client reads.
concepts/stale-while-revalidate-cache — show safe local or bundled data before fetching fresh data in the background.
concepts/cqrs and concepts/materialized-view — XP events are the reconstructable write model; leaderboard rows are a rebuildable read model.

Patterns extracted¶

patterns/durable-client-outbox-with-settled-overlay — preserve an acknowledged client-side intent until a live read confirms it.
patterns/eventual-readiness-state-machine — make temporary provisioning convergence a normal client state.
patterns/mutation-aware-sparse-revalidation — selectively revalidate data classes affected by a completed mutation.
patterns/access-check-before-idempotent-provisioning — take the returning-user fast path while provisioning new users safely.
patterns/async-projected-read-model — rebuild leaderboard rows from XP events using scheduled and incremental automation.

Caveats¶

The post does not name the static host, CDN, platform-edge implementation, internal provisioning orchestrator, analytics platform, local-store technology, retry backoff policy, or notification delivery provider.
It does not specify authentication/session semantics, Jira API quotas, data retention, write idempotency enforcement, conflict handling, or the maximum consistency lag for provisioning and Jira reads.
“Real-time” is product framing; the stated architecture intentionally accepts eventual consistency and scheduled recomputation for several paths.
The results are a single event deployment. There are no p95/p99 latency distributions, error rates, load-test methodology, or comparison with a bespoke event-backend architecture.
The mid-event deployment outage is attributed to an upstream infrastructure change, but the failure mechanism, restoration action, and recurrence prevention are not detailed.