The Atlassian System Design Interview — Jira, Confluence, and Team-of-Teams Scale

The Atlassian system design interview is an enterprise SaaS design interview wearing a collaboration-product hoodie. The best answers do not start with a load balancer and end with Kafka. They start with the actual product constraints: Jira issues that can be customized into almost anything, Confluence pages with nested permissions and years of history, Marketplace apps that extend core workflows, enterprise tenants that care about audit logs and data residency, and teams that work across time zones without losing context.

In 2026, Atlassian interviews are especially sensitive to cloud scale and migration judgment. The company has spent years moving customers from server and data center deployments to cloud. That means the design bar is not just, "Can you shard a database?" It is, "Can you build a system flexible enough for a ten-person startup and a 100,000-person enterprise without making either miserable?" If you can speak clearly about tenant isolation, permissions, search, eventing, workflow customization, and operational ownership, you will sound like you understand the company.

What the loop is trying to measure

The system design round usually sits inside a broader loop: recruiter screen, technical phone screen or coding exercise, one or two technical onsite rounds, a system or architecture round, and a values or management round. Senior and staff candidates should expect the system design conversation to carry a lot of weight. Atlassian is looking for engineers who can work in a team-of-teams environment where platform choices become contracts for many product teams.

The rubric usually has six dimensions:

• Product modeling. Can you turn Jira, Confluence, or Bitbucket-style product behavior into clean entities and APIs?
• Enterprise constraints. Do you remember permissions, auditability, admin controls, data residency, SSO, and compliance?
• Scale and reliability. Can you reason about hot tenants, regional outages, background jobs, and degraded modes?
• Extensibility. Jira and Confluence are platforms. Marketplace apps and automation rules cannot be an afterthought.
• Search and collaboration. Users expect comments, mentions, notifications, page history, and cross-product search to feel instant.
• Migration judgment. Can you evolve a monolith or legacy deployment into cloud services without breaking customers?

A mid-level answer can be technically correct and still miss the round if it feels like a generic social app. A senior answer makes the enterprise SaaS tradeoffs explicit.

Canonical prompt: design Jira issue tracking at enterprise scale

A realistic prompt is: "Design the core system behind Jira issues and workflows." Scope it before drawing boxes. A strong starting set of requirements:

• Organizations contain sites, projects, users, groups, and roles.
• Projects contain issues with comments, attachments, status, priority, assignee, labels, custom fields, links, and history.
• Each project can define a workflow: statuses, transitions, validators, automation, and permissions.
• Users need fast issue views, list views, board views, full-text search, notifications, and audit history.
• Enterprise admins need SSO, SCIM provisioning, export controls, data residency, retention, and app governance.
• Marketplace apps can listen to events and add fields, panels, automations, and workflow validators.

For scale, say your design supports 1 million organizations, 50 million active users, 5 billion issues, and peak write bursts during large enterprise workdays. You do not need to claim those are Atlassian's exact numbers. The point is to pick numbers large enough to force partitioning, search indexing, and async processing.

Data model and tenancy

Start with tenancy because it shapes everything. The clean model is org -> site -> project -> issue. Most operational tables should include tenant_id or site_id as the first partitioning dimension. A small customer can live entirely inside one logical partition. A giant customer may need project-level subpartitioning, dedicated read replicas, or a tenant-specific cell.

Core tables:

| Entity | Important fields | Design note | |---|---|---| | Issue | issue_id, site_id, project_id, type, status, assignee, reporter, timestamps | Keep core fields narrow and stable. | | Custom field value | issue_id, field_id, typed_value, text_value | Custom fields should not mutate the issue schema. | | Workflow | workflow_id, project_id, statuses, transitions, validators | Version workflows so old issues remain interpretable. | | Comment | issue_id, author_id, body, visibility, created_at | Comments are append-heavy and permissioned. | | Issue event | event_id, issue_id, actor, event_type, payload, created_at | The event log powers audit, notifications, automation, and indexing. |

The high-signal move is to separate the transactional source of truth from read-optimized projections. Issues and comments live in a relational or strongly consistent document store partitioned by tenant. Search, boards, reports, and notifications consume the issue event stream and build their own projections. That gives Jira-style flexibility without making every page view run a 14-table query over custom fields.

Architecture that sounds Atlassian-specific

A good architecture has these components:

1. API gateway and identity layer. Authenticates users, resolves tenant context, enforces rate limits, and calls the permission service.
2. Issue service. Owns issue creation, edits, comments, attachments metadata, and workflow transitions.
3. Workflow engine. Evaluates transition rules, validators, required fields, and automation triggers. It must be versioned and deterministic.
4. Permission service. Computes whether a user can view, edit, transition, administer, or export an issue. Cache aggressively, but invalidate carefully on group and role changes.
5. Event bus. Every issue mutation emits an ordered event per issue or project. Kafka, Pulsar, or a managed equivalent is fine.
6. Search/indexing pipeline. Consumes events and updates OpenSearch/Elasticsearch-style indexes for issue text, custom fields, comments, and links.
7. Notification service. Mentions, watched issues, assignment changes, SLA breaches, and digest emails. Deduplicate and batch.
8. Automation/app platform. Marketplace apps and customer automation consume events through a controlled extension layer.
9. Audit and compliance store. Immutable log with retention policies, export, and admin search.

The detail that separates a strong candidate: call out consistency choices. Issue transitions should be strongly consistent for the issue itself. Search can be seconds behind. Notifications can be minutes behind if the queue is overloaded. Audit logs should be durable before the write is acknowledged for enterprise tenants. Marketplace webhooks can be at-least-once with idempotency keys.

Confluence-style variant: pages, history, and collaboration

If the prompt shifts to Confluence, the primitives change. Pages live in spaces, have parent-child trees, version history, comments, mentions, attachments, and access restrictions. The trap is treating it like a simple CMS. Confluence is a collaborative knowledge graph with permissions.

For page editing, choose the collaboration model consciously. For normal enterprise docs, optimistic locking plus version merge may be enough. For real-time collaborative editing, discuss OT or CRDTs, presence, and conflict resolution. The storage model should keep the canonical page content, a version log, attachment metadata, and search projections. Page trees need fast move operations, but tree moves are permission-sensitive and can affect thousands of descendants, so large moves should run as background jobs with progress and rollback.

Search is central: title, body, attachments, comments, labels, and page ancestry all matter. The index must include permission filters. A common failure is to say, "Search service returns matching pages," without explaining how it prevents a user from seeing a restricted page title in results. The safe pattern is indexing enough permission metadata to filter at query time, plus a final permission check before rendering.

Team-of-teams design

Atlassian's engineering model rewards designs that let many teams build independently. Say this out loud. The issue service should own issue invariants. The workflow team owns transition semantics. The search platform owns indexing contracts. The Marketplace team owns extension safety. Product teams subscribe to events instead of reading each other's databases.

This is where API contracts matter. Define stable domain events such as IssueCreated, IssueTransitioned, CommentAdded, and PermissionChanged. Include schema versioning, replay support, and backwards compatibility windows. If you mention that breaking an event schema can break dozens of internal teams and thousands of Marketplace apps, you will sound like someone who has lived with platform software.

Common failure modes

• Ignoring custom fields. Jira's flexibility is the point. If your issue table has 200 nullable columns, you missed it.
• Weak permissions. Enterprise collaboration products are mostly permission systems with a UI attached.
• Making search strongly consistent. That burns complexity budget. Make core writes consistent and search eventually consistent with clear user expectations.
• No app story. Atlassian's ecosystem matters. Apps need controlled extension points, not direct database access.
• No migration plan. Staff-level candidates should explain how to move a legacy monolith feature into services behind a strangler facade.
• Over-indexing every custom field. High-cardinality fields and huge tenants can melt search. Add indexing controls and quotas.

Prep plan and interview tactics

Spend one day using Jira and Confluence as an admin. Create custom fields, workflows, permission schemes, automations, and spaces. The product details will make your design less generic. Then mock three prompts: Jira issues, Confluence pages, and an admin/audit system. For each, practice a 45-minute answer with five checkpoints: requirements, data model, APIs, architecture, failure modes.

At senior levels, prepare migration stories. Atlassian likes candidates who can explain how to carve services out of a monolith, keep compatibility for large customers, and avoid forcing every product team to migrate at once. Have a story about an interface you owned that other teams depended on.

For leveling and negotiation, Atlassian usually values enterprise SaaS experience, cloud migration work, platform ownership, and cross-team influence. Senior candidates should emphasize operating production systems, not just building features. Staff candidates should bring examples where they changed how multiple teams shipped, reduced incident load, or created a platform contract that lasted. If you receive an offer, negotiate around level first, then equity and sign-on. A level miss is worth more than a small cash bump.

The winning Atlassian system design answer feels practical, product-aware, and platform-minded. You are not trying to build the fanciest distributed system. You are trying to build a collaboration system thousands of companies can customize for a decade without collapsing under its own flexibility.

Final calibration checklist

In the last five minutes of the interview, summarize the tradeoffs back to the interviewer. Say which paths are strongly consistent, which are eventually consistent, and which are best-effort. For a Jira design, the issue transition and audit event are the critical path; search indexing, email, and Marketplace webhooks can lag. For a Confluence design, page save and version history are critical; thumbnails and recommendations can lag. This crisp classification helps the interviewer see senior judgment.

Also name the customer blast radius. A small bug in workflow validation could block one project; a bad permission-cache invalidation could expose data across a tenant; a malformed event schema could break many internal consumers. Senior candidates should propose guardrails: tenant-scoped feature flags, canarying by site, replayable events, schema compatibility tests, and operational dashboards per tenant. Atlassian-style scale is not only global traffic; it is the long tail of customer-specific configurations that must keep working after every release.

Sources and further reading

When evaluating any company's interview process, hiring bar, or compensation, cross-reference what you read here against multiple primary sources before making decisions.

• Levels.fyi — Crowdsourced compensation data with real recent offers across tech employers
• Glassdoor — Self-reported interviews, salaries, and employee reviews searchable by company
• Blind by Teamblind — Anonymous discussions about specific companies, often the freshest signal on layoffs, comp, culture, and team-level reputation
• LinkedIn People Search — Find current employees by company, role, and location for warm-network outreach and informational interviews

These are starting points, not the last word. Combine multiple sources, weight recent data over older, and treat anonymous reports as signal that needs corroboration.

Related guides

• The Airbnb System Design Interview in 2026 — Search, Ranking, and Trust-and-Safety Scale — Airbnb's system design loop is FAANG-flavored but has three distinctive axes: search-and-ranking, trust-and-safety, and marketplace dynamics. Here's how the loop actually grades and what a strong answer looks like.
• Atlassian Software Engineer interview process in 2026 — coding, system design, behavioral rounds, and hiring bar — What to expect in the Atlassian Software Engineer interview loop in 2026, including coding, system design, behavioral calibration, hiring-bar signals, and a focused prep plan.
• The Cloudflare System Design Interview — Edge Networking, Workers, and DDoS at Scale — Cloudflare system design interviews reward candidates who understand edge architecture, control-plane propagation, request isolation, and abuse-resistant systems. This guide maps the 2026 bar for networking, Workers, and DDoS-style prompts.
• The Netflix System Design Interview: Streaming Scale, CDN, and Microservices — Netflix's system design loop is the FAANG loop tuned for streaming video, chaos engineering, and a microservices stack older than most of the candidates interviewing. Here's how they actually grade it.
• The Shopify System Design Interview — Commerce Scale, Ruby, and Pair-Programming — Shopify's system design round isn't like Google's. It cares about commerce-specific correctness, multi-tenant isolation, pair-programming culture, and how to reason about a Ruby monolith at scale. Here's what they grade on.