Help desk ticket system case study
Imagine a multiplayer game launches a new season. Players report login problems, matchmaking bugs, lost rewards, and suspicious behavior while the support team tracks a live outage affecting every match. This case study follows that team as it stores, finds, prioritizes, and connects player reports. Each requirement points toward a data behavior, and each behavior can be supported by a suitable structure.
The scenario
A game-support team receives reports from players. Each report has an ID, title, priority, assignee, tags, and optional links to related incidents. The team needs to:
- Create and retrieve a player report by ID.
- Ignore a duplicate event sent by an external system.
- Put ordinary player reports in the order they arrived.
- Undo the most recent report update when a specialist makes a mistake.
- Handle urgent game incidents before routine questions.
- Group reports by tag or assignee.
- Find reports related to the same game incident.
Follow the system as it grows
Start with the simplest useful representation, then add a structure when a new requirement makes the first choice awkward. Each page keeps the same ticket-system context and calls out what the new structure solves and what it still cannot solve.
- A bounded array can represent the four on-call support slots.
- A list can preserve a growing report log.
- A dictionary can find a report by ID.
- A set can reject repeated events.
- A queue can assign ordinary reports first in, first out.
- A stack can undo the most recent update first.
- A priority queue can handle the most urgent work first.
- A graph can connect reports that belong to the same incident.
Match needs to data structures
| Requirement | Question the program asks | Data behavior needed |
|---|---|---|
| Store bounded on-call slots | “Which of the four support slots is active?” | Fixed indexed slots |
| Open a player report | “Where do I store this report?” | Add an item to a flexible list |
| View one report | “What is report GS-2042?” | Find by key |
| Avoid duplicate events | “Have I processed event match-8-retry?” | Check membership |
| Assign the next report | “Which player report arrived first?” | Remove the oldest item |
| Undo a report update | “What changed most recently?” | Remove the newest action |
| Escalate an outage | “Which matchmaking incident is most urgent?” | Remove the highest-priority item |
| Filter by tag | “Which reports are tagged matchmaking?” | Group values by key |
| Follow related work | “Which reports connect to this outage?” | Traverse connections |
Notice that these are different jobs. A fixed array works for the four scheduled on-call slots, while a list is more comfortable when player-report volume changes. Storing every report in a single list would work at first, but it would force the program to scan the list again and again for jobs that have better representations. A dictionary can find a report by ID, a set can remember processed events, a queue can preserve arrival order, and a priority queue can surface an urgent game outage.
Tags and assignees can be represented with dictionaries whose values are groups of reports. Related incidents can be represented as a graph, where each report points to its neighbors. The right choice depends on which operations the game-support team needs most often and how large the report collection can become.
Start with one player report
The examples in this case study use one C# player-report record:
public record Ticket(string Id, string Title, int Priority, string? Assignee);The Ticket describes one thing. The next question is how to organize many tickets for each job the system performs.
The sequence is useful as a concrete companion to the general data-structure discussion. Each structure solves one requirement and leaves the other responsibilities to their own representation.