Automating research participant recruitment and scheduling
Workflow system design with third-party integrations.
Screener intake, eligibility matching, calendar booking, notifications, incentive payout; handle no-shows and idempotency.
What's really being asked
This is a workflow system design question centered on orchestrating external services dependably. The interviewer wants components, a clear data flow, a state machine for the participant lifecycle, and attention to failure modes like no-shows and webhook reliability.
The full answer
Lay out the components. A screener and intake service collects applicants and stores responses. An eligibility and matching service filters applicants against study criteria and quotas. A scheduling service integrates a calendar API to expose researcher availability and book slots, avoiding double-booking with locking. A notification service sends confirmations and reminders via an email and SMS API. An incentive service triggers payout through a payment or gift-card API once a session is completed and verified. Model the participant as a state machine: applied, screened, eligible, scheduled, attended or no-show, paid. Data flows from intake through matching to scheduling, with events driving notifications and payouts. Address reliability: process provider webhooks idempotently, retry failed sends, handle cancellations and reschedules, and reconcile payment status. Add consent capture and audit logging.
The mistakes people make
Listing calendar, email, and payment APIs without a data flow or lifecycle. Ignoring no-shows, cancellations, and double-booking. Assuming external calls always succeed, with no retries or idempotency. Triggering payment before verifying attendance. Skipping consent and personal-data handling.
What usually comes next
How do you prevent double-booking the same slot. How do you make payment exactly-once despite webhook retries. How do you enforce study quotas across concurrent applicants.
A concrete example
An applicant submits the screener; the matching service marks them eligible and decrements the remaining quota atomically. They pick a slot; the scheduling service places a hold, books it through the calendar API, and moves the state to scheduled. The notification service sends a confirmation and a day-before reminder. After the session the researcher marks attended, which transitions to attended and enqueues an incentive; the payment API issues a gift card, and its webhook, processed idempotently by a payout ID, marks the participant paid even if the webhook fires twice.
Interview question
Why process the payment provider's webhook idempotently using a payout ID in this system?
- a.So a retried or duplicated webhook does not pay the same participant twiceCorrect
- b.Because webhooks cannot carry any identifying data
- c.To make payouts faster than synchronous calls
- d.To avoid needing a state machine for the participant
Why? this is the answer
Providers retry webhooks, so keying on a payout ID ensures a duplicate delivery is recognized and not double-paid; the other options misstate webhook behavior and design needs.
Just read this? Test yourself on what you have been reading.
- #system-design
- #research-ops
- #api-integration
- #workflow
- #state-machine
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on system-design — each one lists the topics its interview covers.
See open roles