Design Jira

Problem Low-level design of a Jira-like issue tracker: projects, issues, workflows, users, comments, boards.

Requirements

• CRUD for issues (type, priority, assignee, reporter, labels, attachments); configurable per-project workflows (status graph, e.g. Open → In Progress → In Review → Done) with enforced legal transitions; comments and activity history; boards (kanban/scrum) as filtered views; search/filter.

Core design

• Classes: Project(key, workflow, members), Issue(id, type, summary, status, assignee, reporter, watchers, comments, history), Workflow as a directed graph of Status nodes with Transition edges (allowed roles, validators, post-actions) — a state machine object owned by the project, not hard-coded enums.
• transition(issue, targetStatus, actor): validate edge exists + actor permitted + validators pass → apply, record HistoryEntry, fire events (observer for notifications/webhooks).
• Board(filter, columns mapped to statuses) renders issues by query — boards don't own issues.

Discussion points

• Why workflow-as-data beats status enums: per-project customization without code changes — the key design insight interviewers look for.
• Patterns to justify: state (transitions), observer (notifications), command/memento (history, undo), factory (issue types), specification/builder (search filters).
• Extensibility probes: custom fields (EAV vs JSON column trade-off), sub-tasks and issue links (self-referential associations), permissions (role checks at service boundary).