Design JIRA — Handling Concurrent Edits to the Same Ticket

Problem Statement

Design a system like JIRA (issue tracking). The core focus of this round:

How do you handle conflicting changes to the same ticket? For example, when two people are simultaneously updating the same JIRA ticket's description.

The interviewer cares most about: how is a conflict detected, and how is an error communicated to the second person who updates a few seconds after someone else already did?

Requirements

• Multiple users can view and edit the same ticket
• Concurrent updates to the same field must be detected
• The second (conflicting) writer should be notified their change is stale
• System should scale to many concurrent users

What the Interviewer Expects

1. Naive lock-based approach — take a row lock on the ticket during update. Interviewer will push back: this blocks reads, doesn't scale, and doesn't gracefully communicate conflicts.

2. Optimistic concurrency control (preferred):

   • Track a last_modified timestamp (or version number) per ticket
   • When a user opens a ticket (GET), record their last_read_timestamp for that session
   • On UPDATE, compare: if the ticket's current last_modified > the user's last_read_timestamp, someone else edited it in between → reject with a conflict error

3. Two-table design:

   • Table 1: session_id → ticket_id → last_read_timestamp (records when each session last read a ticket)
   • Table 2: ticket_id → description → last_modified (the actual ticket data)
   • On update: check table 1's read time vs table 2's modified time

4. Conflict resolution options — reject and ask to refresh, auto-merge non-conflicting fields, or show a diff for manual resolution.

Follow-ups

1. How would you handle real-time collaborative editing (like Google Docs) instead of last-write-wins?
2. How do you notify User B in real-time that User A just updated the ticket? (WebSockets, polling)
3. What if you want field-level conflict detection instead of whole-ticket?
4. How would version numbers compare to timestamps for conflict detection? Trade-offs?
5. How do you handle clock skew across distributed servers if using timestamps?