Sampling 5% of users for a one-time survey

WHAT THIS TESTS This evaluates whether you can separate two concerns: stable random sampling and durable once-only state, and implement both efficiently for millions of users. It rewards deterministic design and awareness of write amplification and concurrency.

A GOOD ANSWER COVERS For sampling, do not roll a die per request. Hash the user ID with a survey-specific salt and take modulo one hundred; if the result is under five, the user is in the eligible five percent, and this is stable across requests for free. For the once-ever constraint, you need durable state: a record keyed by user ID plus survey ID marking that the survey was shown, stored in a fast key-value store such as Redis with persistence or a compact table. Before showing, check the marker; if absent and the user is eligible and active today, show it and write the marker atomically. Make the check-and-set atomic, for example, a single set-if-not-exists, so concurrent requests from the same user cannot both display it. Writes happen only once per shown user, keeping load proportional to surveys shown, not total traffic.

COMMON WRONG ANSWERS Sampling randomly per request, so a user may qualify intermittently and see it on a later request. Tracking 'shown' in a cookie or memory, which fails across devices and restarts. Writing to the database on every request to record eligibility. Ignoring the race where two simultaneous requests both pass the check and both display.

LIKELY FOLLOW-UPS How do you expire or clean up markers after the survey ends. How do you ensure exactly five percent rather than approximately. How would you target only daily active users without scanning everyone.

ONE CONCRETE EXAMPLE A user opens the app; you compute hash(userId plus surveyId) mod 100 equals 3, so they are eligible. You issue SETNX on key shown:surveyId:userId; it succeeds, meaning first time, so you display the survey. Their next session computes the same hash but SETNX fails because the key exists, so it is never shown again. Total writes equal the number of users actually surveyed, roughly five percent of actives, not every request.