Design a Project-to-Contractor Matching System

hard

System Design ML System DesignReported Aug 2026

Design a two-sided platform that connects posted work opportunities with independent contractors. Discuss the most important data-modeling and product tradeoffs, how candidate lists are produced and ordered, and how the system can learn from observed results without amplifying the exposure patterns that already exist in historical data.

Constraints and assumptions

Each project describes the required skills, timing, workload, location or time-zone restrictions, and budget.
Each contractor describes their skills, availability, preferences, rate, and eligibility to work.
A contractor may qualify for many projects but has finite capacity for simultaneous work.
Both parties need explanations for recommendations and may reject a suggested match.
New projects and contractors usually have very little behavioral history.

Clarifying questions to explore

Does the product return a ranked list, assign work automatically, or support mutual choice?
Which constraints are strictly non-negotiable?
What outcome counts as a successful match, and when is that outcome observed?
How much do fairness, diversity, and exploration matter for the product?

Separate absolute eligibility rules from softer preferences, and define the core entities: projects, contractors, availability, interactions, and outcomes.

This section should address:

Hard eligibility checks versus soft preference signals
Time-varying availability and limited concurrent capacity
A trustworthy skill taxonomy with evidence of proficiency
Consent, privacy, and explainability requirements

Design candidate generation, scoring, cold-start behavior, and a mechanism for mutual acceptance.

This section should address:

High-recall retrieval that runs before expensive ranking
Constraint-aware scoring and calibration
Exploration for brand-new projects and contractors
Capacity constraints and two-sided marketplace effects

Define offline and online metrics, feedback loops, failure handling, and monitoring for bias or opportunity concentration.

This section should address:

Match quality beyond simple click engagement
Counterfactual or randomized evaluation methods
Exposure and acceptance funnels
Drift, abuse, and unfair-allocation detection

Follow-up questions

How would you stop a small number of highly popular contractors from receiving nearly all opportunities?
How can the system learn when contractors can only accept or reject matches that were shown to them?
What should happen when no available contractor satisfies every hard constraint?

BackBack to problems

Design a Project-to-Contractor Matching System

hard

System Design ML System DesignReported Aug 2026

Constraints and assumptions

Each project describes the required skills, timing, workload, location or time-zone restrictions, and budget.
Each contractor describes their skills, availability, preferences, rate, and eligibility to work.
A contractor may qualify for many projects but has finite capacity for simultaneous work.
Both parties need explanations for recommendations and may reject a suggested match.
New projects and contractors usually have very little behavioral history.

Clarifying questions to explore

Does the product return a ranked list, assign work automatically, or support mutual choice?
Which constraints are strictly non-negotiable?
What outcome counts as a successful match, and when is that outcome observed?
How much do fairness, diversity, and exploration matter for the product?

Separate absolute eligibility rules from softer preferences, and define the core entities: projects, contractors, availability, interactions, and outcomes.

This section should address:

Hard eligibility checks versus soft preference signals
Time-varying availability and limited concurrent capacity
A trustworthy skill taxonomy with evidence of proficiency
Consent, privacy, and explainability requirements

Design candidate generation, scoring, cold-start behavior, and a mechanism for mutual acceptance.

This section should address:

High-recall retrieval that runs before expensive ranking
Constraint-aware scoring and calibration
Exploration for brand-new projects and contractors
Capacity constraints and two-sided marketplace effects

Define offline and online metrics, feedback loops, failure handling, and monitoring for bias or opportunity concentration.

This section should address:

Match quality beyond simple click engagement
Counterfactual or randomized evaluation methods
Exposure and acceptance funnels
Drift, abuse, and unfair-allocation detection

Follow-up questions

How would you stop a small number of highly popular contractors from receiving nearly all opportunities?
How can the system learn when contractors can only accept or reject matches that were shown to them?
What should happen when no available contractor satisfies every hard constraint?

Design a Project-to-Contractor Matching System

Constraints and assumptions

Clarifying questions to explore

Part 1: Requirements and data model

Part 2: Retrieval and ranking

Part 3: Evaluation and operations

Follow-up questions

Design a Project-to-Contractor Matching System

Constraints and assumptions

Clarifying questions to explore

Part 1: Requirements and data model

Part 2: Retrieval and ranking

Part 3: Evaluation and operations

Follow-up questions