Designing a Ticketing System

A ticketing system tracks work items (bugs, features, tasks) through defined workflows.

Data Model

projects(id, name, key, owner_id, settings)

issues(
  id, project_id, type,        -- Bug, Story, Task, Epic
  title, description,
  status,                       -- Todo, In Progress, Done
  priority,                     -- Critical, High, Medium, Low
  assignee_id, reporter_id,
  parent_id,                    -- Epic → Story → Subtask
  sprint_id, created_at
)

comments(id, issue_id, author_id, body, created_at)
attachments(id, issue_id, file_url, size)
workflow_transitions(from_status, to_status, role_required)

Issue Hierarchy

Epic
  └── Story
       ├── Subtask 1
       └── Subtask 2
Bug
Task

Workflow Engine

State machine governs allowed transitions:

Todo → In Progress (any assignee)
In Progress → In Review (assignee)
In Review → Done (reviewer)
In Review → In Progress (reviewer, if changes needed)
Done → Reopened (any)

Search

Jira Query Language (JQL) style search:

project = BACKEND AND
assignee = currentUser() AND
status != Done AND
priority IN (High, Critical)
ORDER BY created DESC

Implement with Elasticsearch for full-text + filters.

Notifications

Trigger events:

• Issue assigned to you
• Comment on your issue
• Issue status changed
• Mentioned in comment (@username)

Fan-out via Kafka to notification service.

Sprint Board

Active Sprint:
Todo | In Progress | In Review | Done
[T1] |    [T3]     |   [T5]    | [T2]
[T4] |             |           | [T6]

Burndown chart: Story points remaining vs time.

Permissions

Org Admin   → All projects
Project Admin → Project settings
Member      → Create/edit issues
Viewer      → Read only

Conclusion

Ticketing systems are fundamentally workflow engines on top of flexible data models, with search, notifications, and reporting as core services.