Skip to content

SYSTEM Cited by 1 source

Atlassian Pre-computation Framework

The Pre-computation Framework is the platform-layer substrate at Atlassian Jira Cloud that owns "the workflow, task workers, batching, retries, and observability" for async, scope-bounded entity-usage reports consumed by the Jira Optimisation Tools and the Site Optimiser dashboard. It is layered on Atlassian's "internal workflow orchestration engine" (the engine is not publicly named in the 2026-05-14 disclosure) and exposes a "simple contract" that Optimisation Tool implementations plug their domain logic into. (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat)

Why pre-compute

"Optimisation tools only deliver value if they work at Jira scale. That means we can't compute everything on the fly in admin UIs. Instead, we use pre-computation: we run asynchronous reporting jobs that scan Jira data, produce a report for a given scope (for example, a space), and let optimisation tools and UIs consume that report cheaply later." (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat)

The framework's stable abstraction is "workflow + task workers + batching + retries + observability" — Optimisation Tools don't have to think about the orchestrator's details; they only plug in the domain-specific scan-step + finalise logic.

Three-phase workflow shape

Each pre-computation workflow follows the same Initialise → Scan-steps → Finalise pattern, formalised by the framework (quoted verbatim from the 2026-05-14 source):

  • Initialise — "prepare for a new job at a given scope (for example, clear or seed intermediate state) while keeping work bounded in time."
  • Scan-steps — "the framework streams Jira entities (work items, screens, fields, and so on) in batches. Tool implementations must be thread-safe, idempotent, and order-agnostic, so the framework is free to parallelise and retry without coordination." See concepts/idempotent-thread-safe-scan-step for the load-bearing scan-step contract.
  • Finalise — "aggregate everything seen during scanning into a durable report that remediation flows and UIs can rely on."

This is the canonical three-phase init-scan-finalise pattern on the wiki.

Scan-step contract

The framework's load-bearing constraint on Optimisation Tool implementations is the trio: thread-safe, idempotent, order-agnostic.

Property What it enables for the framework
Thread-safe Free parallel execution of scan-steps across batches
Idempotent Free retry on transient failure without coordination
Order-agnostic Free batch interleaving / reordering for backpressure

Together these three properties relieve the framework of any need to coordinate scan-step execution; the orchestrator can treat each scan-step batch as an independent retryable unit. See concepts/idempotent-thread-safe-scan-step for the broader concept and a discussion of how this mirrors patterns like MapReduce mappers, stream-processing operators, and pure-function dataflow nodes at other altitudes.

Storage architecture

The framework uses a two-layer state model documented in the 2026-05-14 post under "Tiered State Management: Memcache & Polymorphic Persistence":

  • Memcached for short-lived, multi-step intra-job sharing — working set during a single job's Initialise→Scan-steps→Finalise lifecycle.
  • Jira relational database for persistent pre-computation — the durable per-scope report consumed later by remediation flows and UIs.

The relational layer doesn't use one-table-per-entity-type storage; it uses a small set of generic polymorphic usage tables. The decision rationale is verbatim:

"Naively adding one dedicated table per entity doesn't scale in Jira's multi-tenant architecture: a single new table becomes millions of tables across production, plus indexes and internal database objects."

The two-layer split balances:

  • Scale and cost — fewer tables across tenants, reducing metadata RAM and operational overhead.
  • Performance — still allows efficient, indexed queries over usage data in the cached tier and the persistent tier.

See tiered state management for the broader pattern, and polymorphic usage tables for the multi-tenant DB-design contribution.

Refresh policy

The framework supports both:

  • Periodic recomputation — but only for spaces near limits (≈70% utilisation), per the prioritised-refresh strategy. Recomputing every space on a fixed schedule was rejected as "extremely expensive at Jira scale" — "an enormous volume of jobs which will result in huge load and stress on Jira APIs, Orchestrator, and the database, without clear customer benefit."
  • Ad-hoc on-demand recomputation — "admins can run ad-hoc reporting jobs for specific spaces/schemes whenever they want fresh data" — exposed at the Site Optimiser level as the staleness escape hatch.

Decoupled platform / tool evolution

A load-bearing architectural commitment: "This separation means the platform can be improved independently (better batching, parallelism, data sources) while individual optimisation tools focus on domain decisions (what 'unused' means, which recommendations to surface)." (Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat)

Platform-layer improvements (better batching, more parallelism, additional data-source connectors) ship without requiring per-tool changes; per-tool domain logic ships without requiring platform changes. This is canonical platform vs tool separation applied to a pre-computation engine — the "platform" and "tool" terms map to "control-plane substrate that's reused" and "per-domain consumer logic that's purpose-specific" respectively.

Caveats

  • Underlying workflow orchestration engine is not named. "Internal workflow orchestration engine" is referenced but not identified. Atlassian-internal precedent on the wiki includes Fireworks (Firecracker-µVM AI-agent execution) and Bitbucket Pipelines (CI orchestrator), neither of which is the obvious match.
  • Polymorphic-table query patterns are not disclosed. "Still allows efficient, indexed queries over usage data" is asserted but the index strategy is not specified. With "~1M records per entity type, per tenant" across multiple entity types, the polymorphic table can grow to a large composite size; the index / partition / pruning strategy that preserves "efficient, indexed queries" is left implicit.

Seen in

Last updated · 542 distilled / 1,571 read