TechPrufer
Get started
Atlassian
Atlassian logoAtlassian · Feature trail

Jira Platform Re-architecture for Scale

6 posts · Apr 2020 – Dec 2025

What this trail covers

Jira Cloud continues its evolution from a monolithic architecture to a more scalable, microservices-based system. This post details the migration of the Jira database platform from AWS RDS PostgreSQL to AWS Aurora PostgreSQL, involving the conversion of millions of single-tenant databases. Key challenges included managing a massive number of files per database, which required a 'drain-promote-refill' strategy to reduce file counts before conversion. The migration process was orchestrated via AWS Step Functions and leveraged feature flags for rapid cutovers, limiting downtime to under 3 minutes per tenant. The new Aurora clusters offer improved SLAs, autoscaling capabilities, and cost efficiencies by allowing for smaller instance sizes with dual writer/reader access.

All Atlassian trails
  1. How We Unlocked Performance at Scale with Jira PlatformThis post details the re-architecture of Jira Cloud, focusing on the creation of the Jira Issue Service (JIS). It describes the challenges of the previous monolithic, single-tenant database architecture and the need for a cloud-native, multi-tenant platform. Key technical details include the design of JIS for massive scale (up to 1 billion issues per tenant), performance targets (under 15ms SLO for reads), reliability goals (99.999% API uptime), and cost efficiency. The architecture utilizes service sharding, multi-level caching, and resilience patterns like bounded retries and circuit breakers. Read operations are optimized via cache lookups and document store queries with support for `minVersion` for read-after-write consistency. Hydration uses the Command Pattern for parallel bulk requests to resolve related entities. Write operations are batched to a document store, with issue documents split into root and sibling nodes to handle size limits. The post also introduces Jira Scalable Issue Search (JSIS) and Jira Authorization Service (JAS) as core components of the new Jira Platform.
  2. Migrating the Jira Database Platform to AWS AuroraThis post details the migration of millions of Jira tenant databases from AWS RDS PostgreSQL to AWS Aurora PostgreSQL. The primary technical challenge identified was the high file count per database on RDS instances, which caused startup timeouts during the conversion process to Aurora. To address this, a 'drain-promote-refill' strategy was implemented: RDS instances were first 'drained' to a minimum number of tenants, then 'converted' to Aurora clusters by promoting a read replica, and finally 'refilled' with tenants from subsequent drained instances. This process was orchestrated using AWS Step Functions and feature flags for rapid cutovers (under 3 minutes). The migration achieved cost savings, improved reliability (99.99% SLA), and performance benefits from Aurora's autoscaling and dual writer/reader instance access.
  3. From firefighting to future-proofing: Atlassian’s journey with a multi-account strategyThis post details the 'Account Sharding' project to re-design Atlassian's internal cloud platform (Micros) to address scaling issues caused by hitting AWS account limits. It explains the problem of AWS resource and API limits, the impact on deployments and developer experience, and the decision-making process for adopting a multi-account strategy. The strategy involves incrementally adding accounts, analyzing data to adjust decisions, and avoiding immediate evacuation of services from existing accounts due to migration complexity. The post highlights the challenges of resource migration (compute, ephemeral, persistent) and the decision to involve service owners minimally.
  4. Scaling, rearchitecting, and decomposing Confluence CloudThis post details the architectural evolution of Confluence Cloud, moving from a single-tenant to a stateless multi-tenant architecture (Project Vertigo) and then addressing scalability challenges with database connections. It introduces the 'Burning Man' architecture, which involves decomposing the monolith into new services like 'cc-proxy' and 'cc-ledger'. cc-proxy handles routing between the old and new stacks using Nginx and Lua, while cc-ledger uses Spring Webflux, DynamoDB Global Tables, and DAX for low-latency routing decisions. The post also outlines principles for building new services, including multi-region deployments, low latency, security, high availability, metrics focus, and operational excellence.
  5. Using Protobuf to make Jira Cloud fasterThis post details the technical implementation of the Jira Issue Service, a microservice designed to handle Jira issue data. It outlines the phased approach to decomposing the Jira Monolith, with a focus on Phase 1 where the Issue Service acts as an eventually consistent cache. A significant technical contribution is the migration from JSON to Protobuf for inter-service communication, including the rationale for choosing Protobuf, the migration strategy (dual-write, CHECK mode for validation), and the observed performance benefits (reduced CPU, smaller data size, faster serialization/deserialization, lower response time). Learnings regarding Protobuf's NULL handling and Spring integration are also documented.