Architect a 14-day Pro trial with abuse prevention

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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?

ONE 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.

Source: Stripe