Design a referral feature's lifecycle and races

WHAT THIS TESTS This evaluates data modeling, explicit state machines, transactional correctness, and abuse resistance. Referral systems are money-moving flows, so the interviewer wants to see uniqueness guarantees, atomic credit application, and defenses against duplicate and fraudulent claims.

A GOOD ANSWER COVERS Model a referral as its own entity with a referrer_id, a referee identifier, a unique referral code, a state, and timestamps. The state machine moves through sent when the invite is created, accepted when the new user signs up via the code, qualified once any required action is met such as a first purchase, and credited when both parties receive the reward. A unique constraint on the referee, for example one accepted referral per new account, ensures a person cannot be referred twice and claim multiple times. Credit application must be atomic: wrap the state transition to credited and the two ledger inserts in a single database transaction, and guard it with an idempotency key so a retried or concurrent request finds the work already done and does not double-credit. Use a conditional update, transitioning only if the current state is qualified, so two simultaneous requests cannot both succeed. For abuse, block self-referral by comparing identities and signals, rate-limit invites, and add fraud heuristics for disposable emails or device fingerprints.

COMMON WRONG ANSWERS Storing referral state as a loose boolean with no explicit transitions. Omitting the unique constraint, allowing duplicate claims. Applying credits with separate non-transactional writes, so a crash credits one side only. Ignoring idempotency, so a double-tapped accept button pays twice. Forgetting self-referral and fake-account fraud.

LIKELY FOLLOW-UPS How do you prevent the same person creating many accounts to farm credit? Device and payment fingerprints, qualification gates. What if the referee never qualifies? Expire the referral. How do you make the credit application exactly-once under retries? Idempotency keys plus conditional state transitions.

ONE CONCRETE EXAMPLE Alice invites Bob with a unique code. A referral row is created in state sent. Bob signs up via the code; the row moves to accepted with a unique constraint binding it to Bob's account. Bob makes his first purchase, triggering a transition to qualified. A single transaction then conditionally moves it to credited and inserts a $10 ledger entry for each. If Bob's purchase webhook fires twice, the idempotency key and conditional update ensure only one pair of credits is applied.