Atlassian’s platform powers tools like Jira, Confluence, Bitbucket, and Trello. These products rely on multi-tenant SaaS architectures and complex plugin ecosystems. Your design must support millions of enterprise users while safely enabling many organizations to customize behavior, data models, and integrations.

Real-world context: Atlassian serves 300,000+ customers across Cloud (multi-tenant SaaS) and Data Center (customer-managed deployments), ranging from small startups to Fortune 500 enterprises. This creates extreme variance in data volume, customization depth, and operational requirements across customers, directly shaping architectural decisions on isolation, extensibility, and scale.

At Atlassian scale, the hard part is not CRUD. The real challenge is enabling collaboration and deep customization while maintaining safety in a shared platform. Every architectural decision must account for tenant isolation, plugin failures, and eventual consistency, all without degrading the experience for other customers. Strong designs treat extensibility as a first-class requirement and view isolation and observability as core system capabilities, not add-ons.

course image
Grokking System Design Interview: Patterns & Mock Interviews
A modern approach to grokking the System Design Interview. Master distributed systems & architecture patterns for System Design Interviews and beyond. Developed by FAANG engineers. Used by 100K+ devs.
Intermediate
26hr
Start Learning

The following diagram illustrates the high-level ecosystem of an Atlassian-style platform.

atlassian_ecosystem_overview
The Atlassian platform relies on shared core services supporting distinct products and a vast plugin ecosystem

Approaching an Atlassian System Design interview question

Every Atlassian System Design interview begins with a broad scenario. You might design a system like Jira to manage issues for enterprise teams. The first step is to clarify the context. Ask whether the system runs in Atlassian Cloud or Atlassian Data Center. In Cloud, you design for row- or shard-level tenant isolation. In a Data Center, the isolation boundary is often the deployment itself, so the trade-offs shift toward scale-up strategies, indexing efficiency, and plugin safety. Your architectural choices regarding database isolation depend on this distinction.

Next, you must identify core actors. Most products serve distinct personas, such as administrators, end users, and developers. Understanding user needs allows you to map permission boundaries and API surfaces. You must extract product-specific constraints once actors are defined. The plugin model is a defining characteristic of the Atlassian ecosystem. Any system you design will likely expose hooks for third-party developers. You should think ahead about how to embed plugin execution safely. This must happen without compromising the core platform’s stability.

Finally, you must design for customization at scale. Thousands of organizations will customize workflows or install plugins. Anticipate follow-up questions regarding schema extensions and isolated execution environments.

Tip: Explicitly ask about the “Day 1” vs. “Year 5” scale. Interviewers want to see a design that works now. It must also have a clear path to evolve as data volume explodes.

The next step is to ground your design in specific user behaviors. This follows the establishment of the high-level approach.

User workflows and use cases

Your first job is to map the core workflows before jumping into components. Every design decision flows from how real users interact with the system. An engineer might create an issue and assign it to a teammate. A manager might filter issues by label across multiple projects. These stories imply specific technical requirements. The system must support real-time updates via WebSockets or long-polling. It must enforce strict permission scopes and support extensibility via a plugin framework.

These workflows anchor your architecture. Your storage design depends heavily on how issues are queried. Users might filter by custom fields or text search. Your caching strategy depends on user session data and the frequency of search filters. The API layer must enforce role-based access controls and organizational separation. A user in one tenant cannot access data in another. The plugin system must be resilient. The core system must remain operational if a plugin fails. Start by observing how real users interact, then reverse-engineer your components.

Watch out: Consider the “write-heavy” nature of automated workflows. Users read more than they write. However, automated bots and CI/CD pipelines can generate massive write spikes. Your system must handle this load.

You must quantify the load to justify your infrastructure choices once workflows are defined.

Estimate scale and multi-tenancy

You are expected to back your architecture with real-world scale estimates in an Atlassian System Design interview. You might assume 10 million monthly active users for a system supporting thousands of teams. Active projects could number in the hundreds of thousands. Single organizations might generate up to 100,000 issues over time. Read traffic for search and dashboards might hit 1,000 queries per second globally. Writes could land in the low thousands of QPS globally, including issues, comments, status transitions, and automated workflow updates.

The most critical architectural decision at this stage is the multi-tenancy strategy. You generally have two options. These are a shared schema or isolated schemas. All tenants share tables, distinguished by a `tenant_id`, in a shared-schema approach. This is easier to scale horizontally but introduces complexity in enforcing permissions. An isolated schema approach offers superior data isolation and easier compliance. However, it is harder to manage at scale due to the number of database connections.

StrategyProsConsBest Use Case
Shared Schema (Soft Isolation)Cost-efficient, easier to scale horizontally, and simplified schema migrations.“Noisy neighbor” risk, complex application-level security logic, index bloat.Small to medium-sized organizations (SMBs) and free-tier users.
Isolated Schema (Hard Isolation)Strong data security, no data leakage risk, and easier backup/restore per tenant.High infrastructure overhead, difficult to manage thousands of DB connections.Large enterprise clients require strict compliance and performance guarantees.

You should demonstrate tradeoff awareness by suggesting a hybrid approach. You might use a shared schema for small organizations. Large enterprise clients could receive isolated deployments. This signals that you understand operational costs. It also shows you grasp the customer requirements of a SaaS platform.

The following diagram outlines the high-level architecture. This visualizes how these components interact under load.

high_level_architecture_diagram
A scalable architecture separating core application logic from plugin execution and asynchronous background tasks

High-level architecture

You must sketch a high-level system architecture once your scale model is grounded. This reflects extensibility, tenant awareness, and reliability. The flow typically begins with a Load Balancer routing requests to an API Gateway. The gateway handles authentication, rate limiting, and tenant-based routing. Requests then hit the stateless Web/API Tier. This tier handles core CRUD operations and UI rendering. The Plugin Execution Layer is critical to this design. It handles dynamic plugin logic per tenant without blocking the main thread.

Several auxiliary systems ensure performance and reliability beyond the core request path. A Caching Layer stores user sessions and frequently accessed project metadata. This reduces database load. Background Workers manage asynchronous tasks such as email notifications and webhook queues. This ensures that slow operations do not degrade the user experience. A robust Metrics/Monitoring system tracks plugin usage and system health per tenant. Stitch the narrative together when describing this flow. A user creates an issue, and the request is authenticated. It routes to the web tier and triggers plugin hooks via the runtime.

Historical note: Early versions of many issue trackers struggled. They coupled search indexing directly to the write path. Modern designs use event-based eventual consistency. This updates search indices asynchronously, reducing write latency.

A key differentiator in Atlassian’s architecture is how it handles third-party code. This leads us to the plugin ecosystem.

Plugin ecosystem and extensibility

In Atlassian Cloud, app logic is typically out-of-process (either a Forge-hosted runtime or vendor-hosted services), whereas Data Center apps often run in-process within the product runtime.

Extensibility is non-negotiable in Atlassian’s world. The entire product suite is powered by plugins, including custom workflows and macros. You must choose between inline execution and out-of-process execution. Inline execution runs plugin logic inside your app server’s runtime. This is fast but carries risk as faulty code can crash the server. Out-of-process execution runs app logic in an isolated runtime (for example, Forge) or on vendor-hosted infrastructure (for example, Connect-style apps). This is safer but adds latency. A third option is event-based hooks. In this model, plugins receive events asynchronously.

Security and isolation are paramount when running untrusted code. You must enforce RBAC on plugin access to user data. Use JWTs or API tokens to strictly scope permissions. Include timeout limits and retry backoffs to prevent abuse. Plugins should ideally run in a dedicated, isolated execution environment (for example, a Forge-style sandbox or a separate vendor-hosted service), rather than inside the core runtime. Your system must support versioning and provide metadata for the developer experience. Explicitly state that you would expose plugin hooks via a dedicated runtime service using HTTP- or event-based APIs, with strict isolation and sandboxing.

The flexibility of plugins also demands a flexible data layer. This requires a unique approach to schema design.

Data modeling and schema customization

Data modeling in this context supports extensible schemas that evolve over time. Jira tickets have custom fields, workflows, and statuses that vary by organization. A standard relational model with fixed columns cannot support this. You should propose a hybrid schema.

Core entities like Users and Projects are stored in normalized relational tables. However, custom fields are best handled using a JSONB column in PostgreSQL. For rich search across custom fields, stream write events to a dedicated search index while keeping PostgreSQL (including JSONB) as the system of record. This allows semi-structured data to remain flexible without overloading the primary datastore with search concerns.

Your schema design priorities must focus on multi-tenancy and index strategy. Every table must scope rows by `org_id` or `tenant_id` to ensure isolation. You need an index strategy that optimizes for common filters, such as `project_id`. This avoids unbounded index growth caused by custom fields. Auditability is also critical. Most Atlassian systems log every field change. Design an audit log table that stores deltas of changes. Ensure plugins use namespace prefixes to prevent collisions if they introduce their own tables.

Tip: Mention “Schema Evolution” when discussing custom fields. Explain how you would handle a tenant changing a custom field type. Describe how your data layer would migrate or validate existing data.

The next challenge is ensuring that the system remains reliable even when components fail. This follows the implementation of a flexible schema.

Reliability, consistency, and failure modes

You must demonstrate how your architecture recovers from failure in an Atlassian System Design interview. This is vital when plugins or tenant-specific services go down. Common failure scenarios include plugin execution hanging or search indices falling out of sync. Employ strategies like idempotency to mitigate these. This ensures that all issue updates are retry-safe. Backpressure is also essential. Protect your plugin runtime with queues that shed load when thresholds are exceeded. A hanging plugin should be timeboxed and return a soft-failure fallback.

A critical topic in collaborative systems is the choice between Operational Transformation (OT) and Conflict-free Replicated Data Types (CRDTs). OT was the standard for years. CRDTs have gained popularity for their decentralized nature. They resolve conflicts without a central authority. You might propose using CRDTs for collaborative text editing to ensure deterministic convergence under eventual consistency. You must also address search index lag. The search index might be stale for a few seconds if a user updates a ticket. Design the UI to handle this gracefully.

Isolating plugin failures ensures that core system functionality remains available to the user

You need deep visibility into the system’s behavior to effectively manage these failure modes.

Observability and per-tenant monitoring

Atlassian’s customer base ranges from indie teams to massive enterprises. You must be able to identify exactly what broke and for whom. Your observability strategy should prioritize per-tenant metrics. Track latency per endpoint, plugin error rates, and database query load. Tag these metrics with `org_id`. This allows you to distinguish between a global system outage and a specific tenant abusing a plugin. Tools like OpenTelemetry can be used for distributed tracing across plugin execution.

Consider customer-facing audit logs in addition to internal monitoring. Enterprise admins often need to view system logs relevant to their organization. These include failed logins or plugin timeouts. Your design should include an event ingestion pipeline. This feeds both internal dashboards and customer-facing audit APIs. You should also implement intelligent alert routing. Trigger PagerDuty alerts only for core service issues. Tenant-specific anomalies might trigger automated throttling or support tickets.

Real-world context: Many SaaS outages are caused by a single “hot” tenant overwhelming a shared database shard. Per-tenant monitoring allows you to spot this “noisy neighbor” immediately. You can throttle them specifically and save the platform for everyone else.

We will now look at how these concepts translate into specific interview questions.

Atlassian System Design interview questions and answers

Design a multi-tenant issue tracking system like Jira

This question tests your reasoning on multi-tenancy and data isolation. Start by clarifying the scale and deployment model. Explain the core entities like users, projects, and issues. Dive into the database strategy next. Discuss the trade-offs between a single database with `org_id` columns versus sharded databases. Conclude by detailing the plugin sandboxing model.

How would you support custom fields per organization?

The interviewer is testing your schema design flexibility here. A strong answer involves proposing a hybrid model. Store core fields in relational columns for performance and integrity. Store extensible fields in a JSONB column. Explain that you would predefine common field types to allow for indexing. This approach balances the need for complex queries with flexibility.

A plugin added by one tenant is causing high CPU usage. How do you mitigate?

This scenario tests failure isolation and observability. Explain that each plugin runs in a sandboxed container with strict resource limits. Your system would enforce timeouts and circuit breakers around plugin execution. The system should automatically throttle the specific plugin if usage spikes. This must happen without impacting the core application. Mentioning that you would expose these metrics to the tenant admin adds a touch of polish.

Describe how you’d implement real-time collaboration in Confluence?

This focuses on state syncing and consistency. Propose using WebSockets (or SSE) for real-time delivery. Use CRDTs for handling concurrent edits. Explain that changes are streamed to all collaborators. They are persisted to the backend via an append-only log. Mention that plugins should hook into these events asynchronously via an event bus. This ensures they do not block the real-time editing pipeline.

How would you onboard a new customer org with zero downtime?

This tests your understanding of CI/CD and multi-tenant onboarding. Your response should outline a specific process. New organization onboarding creates tenant metadata and default configurations in the background. Describe a publish-approve pipeline for plugin deployments. Use staged rollouts and version locking. Include feature flags to allow for instant rollbacks if issues are detected.

Conclusion

The Atlassian System Design interview tests your ability to balance scale, collaboration, and extensibility. Success requires more than just connecting boxes. It demands a deep understanding of multi-tenant trade-offs. You must understand the safety of plugin ecosystems and the concept of eventual consistency. Demonstrate that you can build a robust system suitable for the enterprise. It must also be flexible enough for the individual team.

We can expect these interviews to increasingly focus on AI-driven workflows as platforms evolve. This requires even more sophisticated data pipelines and event-driven architectures. Walk into the room ready to reason about tenant isolation and safe extensibility. Do this with the clarity of a platform architect. You will stand out from the crowd.