Match Tagged Problems to Skilled Programmers at Scale

Scenario

Design a scalable task-assignment system for an enterprise platform that matches incoming, tag-annotated coding problems (e.g., distributed-systems, linux-kernel, go) to available programmers with verified skill sets.

The system must dynamically evaluate programmer availability, maintain fairness in workload allocation, and deliver assignments in real time while scaling to handle global developer pools and traffic spikes.

Requirements

Functional Requirements

• Problem Ingestion: Ingest incoming problems with metadata, difficulty, required skill tags, and SLA deadlines.
• Programmer Availability & Skills: Maintain real-time availability states and skill profiles for programmers.
• Matching Engine: Match problems to qualified programmers (where a programmer must satisfy all required problem tags) maximizing matched volume while respecting capacity limits (e.g., max concurrent tasks per programmer).
• Lifecycle & Feedback: Support accept, decline, and timeout flows, returning unassigned or rejected tasks back to the queue for rematching.

Non-Functional Requirements

• Low Latency: Assignment decision latency must be under 500 ms (p99).
• Fairness: Avoid starving lower-priority problems and prevent overloading a small subset of popular programmers.
• Fault Tolerance & Consistency: Prevent double-assignment of tasks or over-assignment of programmers under concurrent matching rounds.

Scale & Traffic Estimates

• Active Programmers: 200,000 concurrently active engineers.
• Problem Volume: Peak 20,000 incoming problems per minute (~350 problems/sec).
• Skill Taxonomy: 1,000 unique tags; each problem has 1–5 tags; each programmer holds 5–30 verified tags.
• Concurrency Limit: Each programmer can take at most 2 active tasks simultaneously.

Key Areas to Cover

1. Data Model & Graph Formulation: How to model problem requirements and programmer skills, indexing strategy for rapid candidate edge generation, and matching algorithm selection (e.g., maximum bipartite matching vs. online greedy/min-cost max-flow).
2. System Architecture: High-level services (Ingestion, Matcher, State Store, Notification), batching vs. streaming trade-offs (e.g., micro-batching with Hopcroft-Karp vs. pure online matching).
3. Distributed Coordination: Partitioning strategies (by tag cluster, geography, or hash), distributed locking/reservations, and handling cross-partition dependencies.
4. Failure Modes & Churn: Handling disconnects, declined tasks, and partition worker crashes.