Functional Requirements

P0 - Basic features

• Users can create their profile (name, age, gender).
• Users can choose their interests from a platform-provided global list (provided in constructor).
• Users can set partner preferences (age range, gender).
• Users can request the best available profile and choose to accept or decline.
• Once accepted/declined, that profile must never appear again in the user’s feed.
• If two profiles mutually accept, they become a match and appear in each other’s matched list.
• Users can view their matched list at any time.

P1 - Advanced features

• To maximize the number of matched users, every time a user receives a match, their likelihood of appearing on another user’s feed goes down. This prioritizes users who have fewer/no matches.
• Users can buy boost plans to skip the queue and increase their likelihood of appearing in more user feeds.
• Admins can pull reports: total user count, matched users count, top-n users with highest matches, and cohort sizes (gender, age groups).

P2 - Bonus features

• Users can mark each preference as strict vs lenient. If a profile fails a lenient preference, it may still be treated similar to a preferred profile but with lower ranking.
• Users can super-accept a profile, which immediately ranks the sender highest on the receiver’s feed. Each user can super-accept only once in their lifetime.
• super-accept overrides eligibility. If a candidate has an active super-accept toward requester, they are eligible regardless of preference/accept status.

Assumptions

• gender is represented as a string such as "MALE", "FEMALE", "OTHER".
• genderPreference is one of "MALE", "FEMALE", "OTHER", "ANY".
• Age is an integer in years.
• If there is no eligible profile for getBestProfile, return "" (empty string).
• Interest format: an interest string must match the pattern [a-z-]+ (only lowercase letters and hyphen).

Constraints

• 1 ≤ totalUsers ≤ 100000
• 0 ≤ interestsPerUser ≤ 100
• 18 ≤ age ≤ 100
• 18 ≤ minAge ≤ maxAge ≤ 100
• 1 ≤ topN ≤ totalUsers
• All storage is in-memory only; no database usage.
• The platform maintains a fixed set of allowed interests, provided once via the constructor. User-provided interests not present in this allowed set are ignored.

Platform Global Interest List

Method Signatures

0) Constructor

• Initializes the platform with a fixed global allowed-interest set for the entire lifetime of the application.
• The effective allowed-interest set is formed by:
  • Removing duplicates
  • Keeping only items matching [a-z-]+
  (In this problem, tests will provide the complete valid list shown above.)

1) Upsert profile data

2) Get best profile

• Returns the userId of the best available candidate based on the exact eligibility + ranking rules below.
• Returns "" if userId does not exist or if no candidate is eligible.
• This call must not mark the candidate as accepted/declined.

• Candidate must not be the requesting user.
• Candidate must not have been previously accepted or declined by the requesting user.
• Let preferred(requester, candidate) be whether candidate strictly matches requester’s partner preference: age in [minAge, maxAge] inclusive AND (gender matches OR requester genderPreference is "ANY").
• If candidate is unpreferred for requester, candidate is eligible only if candidate has already accepted requester.

1. Super-accept priority (P2): If one or more users have an active super-accept toward userId, then getBestProfile(userId) must return one of those super-accepting users first. If multiple exist, return the lexicographically smallest super-accepting userId.
   After a super-accept from user X to user Y, X must remain above everything else in Y’s feed until Y reacts (accept/decline).
2. Preferred profiles that have already accepted the user (preferred(requester,candidate)=true AND candidateAcceptedRequester=true), ordered by highest mutual interests.
3. Preferred profiles (preferred(requester,candidate)=true AND candidateAcceptedRequester=false), ordered by highest mutual interests.
4. Unpreferred profiles that have already accepted the user (preferred(requester,candidate)=false AND candidateAcceptedRequester=true), ordered by highest mutual interests.

• Boost first (P1): boosted candidates rank above non-boosted candidates within the same bucket.
• Higher mutual interests first.
• Lower match count first (P1: prioritize users with fewer matches).
• If still tied, lexicographically smaller userId first.

3) React to profile (accept/decline)

• If isAccepted == true, this records that userId accepted targetUserId.
• If isAccepted == false, this records that userId declined targetUserId.
• Accept / Decline / Match (Key Definition moved here):
  • If user A accepts user B: record that A accepted B; B must not appear again in A’s feed.
  • If user A declines user B: record that A declined B; B must not appear again in A’s feed.
  • If A accepts B AND B has already accepted A, then A and B become matched and appear in each other’s matched list.
• Returns false if either user does not exist, or if userId == targetUserId.
• If already reacted for same userId and targetUserId, ignore any subsequent reaction (even if different) and return false.

4) List matched profiles

• Returns a list of matched userIds for userId, sorted lexicographically.
• Returns empty list if no matches or user not found.

5) P1 - buy boost

• Marks the user as boosted.
• Boost behavior (Key Definition moved here): boosted users should be prioritized above non-boosted users within the same ranking bucket in getBestProfile. If multiple boosted users tie, use the same tie-breakers (mutual interests, lower match count, lexicographic userId).
• Returns false if user not found.

6) P1 - show stats

• Returns admin stats as a list of human-readable strings (each entry one line).
• Must include:
  • Total user count
  • Matched users count (users with at least 1 match)
  • Comma separated Top-N users with highest match count (descending), including match count in format: userId-matchCount
    Example: user1-12,user11-8,user2-8
    Tie-breaker for same match count: lexicographically smaller userId first.
  • Cohort sizes: gender counts and age buckets (18-25, 26-35, 36-50, 51-100)

7) P2 - super accept

• Each user may super-accept only once in their lifetime.
• Super-accept behavior (Key Definition moved here): After a super-accept from userId to targetUserId, userId must appear at the very top of targetUserId feed (above everything else) until targetUserId reacts (accept/decline).
• If multiple users have an active super-accept toward the same target user, break ties by lexicographically smaller userId first.
• Returns false if invalid users, self-action, or super-accept already used by userId.

Examples

Example 1: Upsert + overwrite semantics + interest filtering + basic ranking by mutual interests

Example 2: Eligibility buckets + accept/decline rules (one-shot reaction) + unpreferred-only-if-accepted + matching + listMatchedProfiles

Example 3: P1 tie-breakers (boost, mutual interests, match count, lexicographic) + P2 super-accept priority + showStats