Design a Streaming Subscription System: Billing, Plan Changes and Payment Retries

You are designing the subscription system for a video streaming service such as Netflix. A member picks a paid plan, is charged automatically at the start of every billing period, can switch to a higher or lower plan whenever they like, and can cancel. The system must always be able to say whether an account may stream and on which plan, and it must collect payments through an external payment provider whose calls are sometimes declined, time out, or fail outright. The interviewer runs the round as an open conversation rather than a puzzle, moving through how subscriptions work, how billing happens, how upgrades and downgrades are handled, how failed charges are retried, and how the system scales. Start with a simple design that works end to end, then go deeper in each area as the interviewer steers. ### Constraints and Clarifications - An external payment provider processes the card charges. You design the service that calls it and records the results, not the card network. - Billing is recurring on a fixed interval (assume monthly unless you decide otherwise). The interviewer gave no plan catalog, prices, regions or traffic figures, so any numbers you use are your own stated assumptions. - Treat the usual billing guarantees as requirements: a member is never charged twice for the same period, and a paying member never loses access because of an internal failure. - Video delivery is out of scope. The playback side only needs a fast answer to "is this account entitled right now, and to which plan's features?" ### Clarifying Questions - Should an upgrade take effect immediately and a downgrade at the next renewal, or should both behave the same way? - After a renewal charge fails, how long does the member keep watching while the system retries, and when does the subscription end? - Are free trials, promotional prices or billing through third parties (app stores, bundles) in scope, or only direct card payments? - Which countries and currencies must be supported, and is tax calculated here or by an external service? - How quickly must a cancellation or plan change become visible to playback: is a few seconds of lag acceptable? ### Part 1 — Model subscriptions and their lifecycle Define the core entities (member account, plan, price, subscription, invoice, payment) and the states a subscription moves through from sign-up to cancellation. Describe the APIs the rest of the product uses to create, read, change and cancel a subscription, and explain how the playback side checks whether an account is entitled to stream. ```hint Think in states and transitions List every event that can change a subscription (a renewal date passing, a charge succeeding or failing, a member action) and decide which state each one leads to. ``` #### What This Part Should Cover - Entities and their relationships, including how plan and price history is preserved over time - An explicit set of subscription states with the transitions and what triggers each one - Management APIs, plus a separate entitlement read that is cheap enough for every playback start - Where the source of truth lives and how other services learn about changes ### Part 2 — Recurring billing Explain how the system finds subscriptions that are due, creates the charge for the new period, calls the payment provider, and records the outcome. Walk through what happens when a billing worker crashes partway through, or when the provider call times out with no answer. ```hint What do you know after silence? Ask what the system actually knows after a provider call that never returned, and what it would need in order to try again without risk. ``` #### What This Part Should Cover - Scheduling due renewals so none is missed and none is processed twice - Charge creation that is safe to repeat, and reconciliation against the provider's own records - A durable, auditable record of invoices and money movements - Handling ambiguous outcomes such as timeouts and provider notifications that arrive late, twice, or out of order ### Part 3 — Upgrades and downgrades A member on a cheaper plan upgrades in the middle of a billing period, and another member downgrades. Describe when each change takes effect, how the amount owed is calculated, and how you stop a plan change from colliding with a renewal that is being processed at the same moment. ```hint Two writers, one subscription Picture a member pressing upgrade while the renewal job is in the middle of charging the old price. Decide which of the two should win and how each finds out about the other. ``` #### What This Part Should Cover - The timing policy for upgrades versus downgrades and its effect on what the member can watch - How the amount due is computed and shown on the invoice - Concurrency control between member actions and billing jobs - What happens when the charge for an upgrade fails ### Part 4 — Failed payments, retries and scale Design the retry policy for declined renewals: when the system tries again, what the member can do and see in the meantime, and when the subscription finally ends. Then explain how the design holds up as the number of subscribers grows and renewals bunch up on the same dates. ```hint Not every decline means the same thing Group the possible failures by whether waiting could help and by who has to act next. ``` #### What This Part Should Cover - Retry scheduling that distinguishes retryable from permanent failures, with member notifications - A grace period whose access rules stay consistent with billing state - Spreading renewal load and keeping the entitlement read path fast as subscribers grow - Protecting the payment provider from overload and recovering from a provider outage ### What a Strong Answer Covers - Starts from a simple, correct design and adds components only where the stated scale requires them - Treats every money movement as safe to repeat and auditable end to end, including reconciliation with the provider - Keeps entitlement consistent with billing state without putting billing or the provider on the playback path - States and defends policy choices (plan-change timing, grace period, retry limits) and flags which ones need product input - Covers failure modes: crashed workers, duplicate or reordered events, provider outages, and concurrent member actions ### Follow-up Questions - The payment provider has a regional outage on your busiest renewal day. What do members experience, and how does the system catch up afterwards? - Finance reports that last month's charges in your records do not match the provider's settlement report. How does your design let you find the difference? - How would you roll out a price increase for existing members that must be announced before it applies? - How would the design change if some members are billed through an app store, where you do not control the charge and only receive notifications?