Design Jira

Problem Statement & Context

Jira is an issue-tracking backbone for software teams: every ticket mutation must respect configurable workflows, custom fields, and project-scoped permissions while staying searchable via JQL and visible on Scrum/Kanban boards within sub-second budgets.

Why this is harder than a CRUD tracker

The naive model is a table of issues with a status column you UPDATE. That breaks on the first real requirement: a transition from In Progress to Done may be forbidden, may require a resolution field, may fire a webhook, and must leave an immutable audit trail. So a status change is not a column write; it is a validated transition against a per-project workflow definition, persisted as an event. On top of that, a board is not the source of truth — it is a projection of issues filtered and ordered by rank, and JQL is a query language that must run with the caller's permissions and a query budget so one expensive search cannot stall a shard.

The numbers and SLOs to anchor on

Assume enterprise tenants with 5k–50k active issues per project and dozens of concurrent board viewers during sprint ceremonies. State the SLOs as first-class, not just API availability: transition latency, board P99, JQL P95, index lag, and webhook success rate. The failure modes those guard against — a lost transition, a stale board rank, a JQL timeout, a webhook storm, a cross-project permission leak — are exactly what an interviewer will push on, so name the one you are optimizing against and tie each component back to it.