Katkat
Back

Design a Support Ticket Processing System

BlinkSoftware Engineer · Onsite
HardSoftware EngineerOnsiteSystem Design

Last updated

This question tests your ability to design a distributed, asynchronous ticket processing system that handles high volume, prioritizes SLAs, and ensures reliable data delivery.

Problem Statement

Design a global support ticket processing system for Blink, a high-growth platform. Customers submit support requests via email, web forms, and mobile apps. Support agents are assigned tickets based on availability, language proficiency, and ticket priority.

Functional Requirements

  • Customers can create, view, and update their tickets.
  • Agents can claim, resolve, or reassign tickets.
  • System must track ticket status (New, Assigned, Pending, Resolved) and history.
  • Real-time dashboard showing the number of active tickets for supervisors.

Non-Functional Requirements

  • Scale to 500,000 tickets per day with burst capacity during outages.
  • Low latency for ticket creation; eventual consistency is acceptable for analytics.
  • High availability and durability: no lost tickets.
  • Strict adherence to SLAs (e.g., first response time under 1 hour).

Your Deliverables

  1. High-level architectural diagram (describe components).
  2. API design for ticket submission and agent assignment.
  3. Data model (choose between SQL/NoSQL and justify).
  4. Strategies for load shedding and handling queue spikes.

Example Constraints

  • Assume an average payload of 2KB per ticket description.
  • Read-to-write ratio is 5:1.
  • Agents are globally distributed, requiring minimal latency for assignment updates.

Hints

Hint 1

Consider using an asynchronous message queue (e.g., Kafka or RabbitMQ) to decouple ticket ingestion from assignment logic.

Hint 2

Think about how to implement a priority-based worker pattern where urgent tickets bypass standard queues.

Hint 3

Evaluate whether a relational database (ACID) is better for ticket state management versus a NoSQL store for high-volume unstructured logs.

Follow-up questions

  • How would you modify your architecture to support 'dead-letter queues' for tickets that fail automated assignment?
  • If a specific support category experiences a 10x traffic spike, what throttling mechanisms would you implement to prevent system collapse?
  • How would you ensure that two agents are never assigned the same ticket simultaneously at scale?