Designing a tiered entitlements backend

WHAT THIS TESTS The interviewer wants a clean data model that separates billing from access control, an entitlement-resolution path the application can call, and correct handling of the messy edges of plan changes.

A GOOD ANSWER COVERS Model plans, features, and limits as data: a plan is a named bundle that grants a set of features and numeric limits, like seats or API calls. A subscription record links an account to a plan with a status, current period start and end, and billing-provider id. Resolve access through an entitlement-check service the application asks, can this account use feature X, what is its limit, rather than hardcoding tier comparisons. Expose endpoints to read the current subscription, list available plans, and request an upgrade or downgrade. Handle upgrades as effective immediately with proration; handle downgrades as effective at the end of the current paid period so you never revoke access the user already paid for, and enforce new lower limits only when the new period begins.

COMMON WRONG ANSWERS Scattering tier checks throughout the code so a new plan requires touching dozens of files. Storing only a tier string with no feature mapping. Applying downgrades immediately and clawing back paid access. Ignoring the billing provider, so a failed payment or refund leaves entitlements out of sync. Not handling proration.

LIKELY FOLLOW-UPS How do you keep entitlements consistent with Stripe webhooks? How do you cache entitlement checks safely? How do you handle a downgrade that exceeds the new seat limit?

ONE CONCRETE EXAMPLE A user on Pro upgrades to Enterprise. The system creates the change immediately, prorates the remaining period, and the entitlement service instantly returns the higher seat and API limits. If instead they downgrade to Free, the subscription is marked to switch at period end; until then they keep Pro access, and at renewal the entitlement service begins returning Free-tier limits, prompting them to remove excess seats.