Design a High-Concurrency Incident Ticket Correlation Platform
Company: Microsoft
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
## Prompt
Design a ticket platform where each ticket is linked to the affected user, correlated with all other relevant tickets for that user, mapped to the responsible system, and enriched with that system's operational status during the incident window. Cover database design, APIs, correlation, and high-concurrency trade-offs.
### Constraints & Assumptions
- Ticket creation must remain available even when a status provider is slow or unavailable.
- A user can have many tickets and one ticket can reference more than one affected system.
- Status history is time-ranged and may be corrected after initial ingestion.
- Correlation results may be eventually consistent but must show their freshness.
### Clarifying Questions to Ask
- What makes two tickets related beyond sharing a user: time overlap, system, symptom, or explicit link?
- Which status systems are authoritative, and how much historical retention is needed?
- How quickly must newly related tickets appear under peak incident traffic?
```hint Keep status history interval-based
A status event needs effective start and end or versioned transitions so a ticket window can be joined to the status that actually applied.
```
```hint Move expensive correlation off the create transaction
Persist the ticket and an outbox event first; enrich and link asynchronously with idempotent workers.
```
### What a Strong Answer Covers
- Ticket, user, system, ticket-system link, explicit relation, and status-interval models.
- Write path independent from asynchronous enrichment and correlation.
- Queries for user history and time-overlapping system status with suitable indexes.
- Idempotency, concurrency, partitioning, hot-incident, and stale-result handling.
- Reprocessing, audit, access control, metrics, and failure recovery.
### Follow-up Questions
1. How would you prevent one major outage from creating a hot partition?
2. How would you recalculate correlations after a system mapping is corrected?
3. Which fields should support full-text or vector search, and which must remain deterministic filters?
Overview: Design a high-concurrency incident ticket platform with user and system links, interval-based status history, asynchronous idempotent correlation, indexed queries, freshness indicators, reprocessing, audit, and hot-incident resilience.