Atlassian System Design Interview Questions

Yes. They are rigorous and comparable to interviews at Google or Dropbox, with a strong emphasis on designing reliable SaaS architectures.

Start with core System Design concepts, particularly around collaboration, versioning, and permissions. Review Atlassian’s product architecture blogs for real-world context and practice with realistic design scenarios.

Mistakes include skipping user collaboration flows, neglecting data integrity under concurrent usage, overlooking permission management, and jumping into architecture without clarifying requirements.

It is extremely important because Atlassian prioritizes correctness, conflict resolution, and auditability—especially in multi-user environments. Interviewers will look for designs that emphasize trust, security, and graceful degradation.

You need a search engine that returns fast, relevant, and permission-aware results. Index articles using a tool like Elasticsearch, enriched with metadata like labels, last-edited timestamps, and user-generated signals (views, comments). Apply permission filters at query time to ensure only visible content is returned. Boost rankings based on recency, team relevance, and personal search history. For scalability, shard by workspace or product, and use background jobs to index new or updated content.

An API gateway should handle authentication, routing, rate limiting, and observability across all Atlassian products. Use a gateway (like Envoy or Kong) to route requests based on service-specific rules. Add middleware to validate API tokens (OAuth2/JWT), throttle traffic, and log metrics. Support multi-tenancy by routing requests through organization- or user-aware layers. It should also include a developer portal for documentation, sandbox environments, and usage analytics.

The goal is to enable real-time editing, versioning, and rollbacks. Store each document as a series of deltas or patches, with a change log. Use operational transforms (OT) or conflict-free replicated data types (CRDTs) for concurrent edits. Keep a master version in the database, with autosave snapshots and metadata for authorship and timestamps. Users should be able to view change history, restore previous versions, and comment on edits.

This system needs to trigger actions based on events, like “when a card moves to Done, send an email.” Store workflows as event-condition-action rules. Use a rule engine to evaluate triggers and conditions in real time. Events are processed through a message queue (e.g., Kafka), where each handler decides whether to act. Workflows should be editable through a UI, stored as JSON, and support branching, delays, and retries for external API failures.

Although it seems front-end, a scalable color picker needs back-end support for theme persistence, accessibility, and team standards. The UI allows color selection from a palette, but the back-end stores mappings of themes to elements (e.g., “status-green” to hex #3c763d). Support organization-wide theme sharing, light/dark variants, and accessibility checks (e.g., WCAG contrast ratios). Store user preferences in a settings DB tied to their Atlassian profile.

Start with a data model where boards contain lists (columns), and lists contain cards. Each card holds metadata (title, labels, comments, attachments). Store this in a document database for quick hierarchy access. Reordering cards uses position fields or a fractional ordering system (e.g., lexorank). Real-time updates use WebSockets or long polling. Boards must support multiple users simultaneously, so add conflict resolution and collaborative editing safeguards.

The challenge here is to efficiently track the size of nested folders and collections. Represent the file system as a tree with each node (file or folder) holding size metadata. When a file is added, moved, or deleted, propagate the size change up the tree. To support fast reads, cache aggregated sizes at each folder level. Use write-through caching and a DAG-style update model if files are shared across multiple folders.