Design an Issue Tracker (Jira)

Jira is Atlassian's flagship: teams file issues (bugs, stories, tasks), attach fields to them, drag them across a board as they progress, and search the pile with JQL, Jira Query Language. Two things make this more than a to-do list with a database behind it. First, no two customers use it the same way, so an issue is not a fixed row. A game studio adds a "platform" field and a bug-triage workflow with a QA-verified state; a legal team adds a "contract value" field and an approvals workflow. Second, it is sold as one hosted product to millions of organizations at once, and a support ticket that leaks between two of them is the kind of incident that ends up in the press. Both facts shape every box in the design. Atlassian's own Cloud architecture and operational practices page says its cloud products share a multi-tenant architecture, and that any request to Jira without a tenant context is rejected.

The Atlassian angle

What the interviewer is listening for in the opening minutes is whether you call this a multi-tenant, permission-aware, tenant-configurable system, because that is the version of the prompt Atlassian is actually asking. A candidate prepped on a generic "design a task manager" reaches for one issues table, a status column, and a WHERE clause on search. The interviewer will pile on until that model breaks. The Jira reality is different on three axes at once. The schema is not fixed: each tenant defines its own fields and its own workflow, so "add a column" is not an option. Reads are filtered by dynamic, hierarchical permissions that can depend on an issue's own field values. Search becomes "SELECT where it matches and this specific user is allowed to see it right now." And the whole thing is one platform serving millions of tenants, so isolation and noisy-neighbor defense are load-bearing, not footnotes. Name those three up front and the rest of the round is you defending a real system instead of retrofitting a hobby app.