Architect a 14-day Pro trial with abuse prevention
Tests stateful billing lifecycle and anti-abuse tradeoffs. Strong answers cover: idempotent trial state machine with scheduled expiry; retention on downgrade; progressive friction via device intel and rate limits; and behavioral monitoring.
What's really being asked
This question evaluates your ability to design a stateful distributed system for subscription billing with precise state transitions, reliable scheduling, and anti-abuse guardrails that balance conversion against fraud. The interviewer cares about idempotency, data retention policies, and how you instrument sign-up flows to detect abuse without adding excessive friction for legitimate users.
The full answer
First, an idempotent trial state machine with explicit states like trialing, active, expired, and grace period. Use scheduled jobs or a time-based ledger to drive transitions, not just client-side timestamps, and ensure the expiration handler is retry-safe. Second, data handling on downgrade: define a retention policy where Pro data is soft-deleted or archived after expiry rather than immediately wiped, preserving user trust while reclaiming resources. Third, notifications via event-driven webhooks or email queues triggered at day 3, day 7, and day 13 to maximize conversion, plus a final receipt of downgrade. Fourth, anti-abuse layers drawn from Stripe signals: risk scoring at sign-up, device intelligence to fingerprint repeat registrations, progressive friction that escalates from CAPTCHA to identity verification only when risk scores cross thresholds, rate limiting on trial creation per device or payment instrument, and behavioral monitoring during the trial to watch for scripted usage patterns. Mention that abuse pollutes product analytics, inflates support load, and increases exposure to payment fraud.
The mistakes people make
Proposing IP blocking as the primary defense, which harms legitimate users behind NAT and is trivially bypassed. Designing a state machine that relies on cron jobs without idempotency guards, leading to double-billing or duplicate notifications. Suggesting immediate hard deletion of trial data upon expiry, which destroys user trust and violates reasonable retention expectations. Ignoring the difference between trial expiration and subscription cancellation, conflating the two states. Failing to mention progressive friction or assuming all users should complete the same heavy verification flow.
What usually comes next
How would you handle timezone edge cases for the 14-day boundary? What happens if the payment method fails when transitioning from trialing to active? How do you distinguish a legitimate power user from an abuser during behavioral monitoring? How would you refactor this if the trial length became customizable per campaign?
A concrete example
Suppose a user signs up for Pro on January 1. Your billing service writes a trial record with an expires_at timestamp of January 15 at 00:00 UTC and emits a TrialStarted event. A scheduler polls expired trials daily; on January 15 it attempts to transition the state to expired, idempotently checking that the current state is still trialing. The job enqueues a downgrade task that archives Pro reports to cold storage, retains project metadata for 90 days, and flips the feature flag to Free. Meanwhile, the sign-up flow ran device intelligence and rate limiting: the same device had already started two trials, so the risk score triggered an SMS verification step before the third attempt. During the trial, behavioral monitoring flagged that the API usage pattern matched a scraper, so Stripe Radar signals were consulted before allowing the trial to convert.
Interview question
Which design best prevents race conditions and duplicate side effects when a distributed scheduler processes trial expirations?
- a.Conflate trial expiration with subscription cancellation to reduce the number of state transitions
- b.Use a cron job that retries failed transitions aggressively without idempotency guards
- c.Rely on client-side timestamps to trigger expiration only when the user is actively connected
- d.Maintain an idempotent state machine where the expiration handler verifies the current state is trialing before transitioningCorrect
Why? this is the answer
The card emphasizes that expiration handlers must be retry-safe and idempotently check the current state before transitioning to avoid double-billing or duplicate notifications. Option B reflects the common mistake of using cron jobs without idempotency guards, while D introduces state conflation errors.
Just read this? Test yourself on what you have been reading.
Read the original → stripe.com
- #billing
- #state-machines
- #fraud-prevention
- #subscriptions
- #system-design
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
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. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles