Billing Calculator: Subscription Fees, Mid-Period Upgrades and Tiered Usage

Implement a billing calculator for a product that charges customers a subscription fee and usage-based fees. In the reported online assessment this was a single problem with four parts and one hour in total, and each part added a new dimension to the previous ones: the first part computes only the subscription fee, and later parts add subscription upgrades and segmented billing. The difficulty reported was having to keep changing earlier code as new dimensions arrived, so structure the first part so that later parts extend it rather than rewrite it. The report does not give the input format or the exact content of each part, and it does not describe the fourth part. The format and the three parts below are assumptions that make the reported dimensions concrete. ```text plans (illustrative) basic fee 20.00 per billing period pro fee 50.00 per billing period usage bands (illustrative, price per API call) calls 1 to 1,000 0.010 calls 1,001 to 10,000 0.008 calls above 10,000 0.005 customer c1, billing period of 30 days (days 0 to 29) day 0 subscribes to basic day 15 upgrades to pro usage 12,000 API calls in the period ``` ### Clarifying Questions - What does the input look like: one record per event, a list of customers with their plans, or calls to methods such as `subscribe`, `upgrade` and `record_usage`? - How is money represented, and where is rounding applied: per line item, per segment of the period, or on the invoice total? - Is the subscription fee charged in advance at the start of the period or in arrears at the end, and does a customer who starts partway through a period pay a full or a partial fee? - Is the billing period a fixed number of days, or calendar months of different lengths? ### Part 1 — Subscription fee Given the plans and each customer's subscription, compute each customer's invoice for one billing period, and the total across customers. In this part the only charge is the plan's subscription fee. ```hint Model for the later parts Represent what a customer is subscribed to over the course of the period, not just a single plan name, and keep money in a representation that stays exact. ``` #### What This Part Should Cover - A data model for plans, subscriptions and invoice line items that later parts can extend - An exact money representation and validated input - Per-customer invoices and the overall total ### Part 2 — Subscription upgrades A customer can upgrade to a more expensive plan partway through a billing period. The invoice must reflect the time the customer spent on each plan. ```hint Price the days Ask what each day of the period should cost the customer before and after the upgrade, and decide where rounding happens. ``` #### Clarifying Questions for this Part - Is the charge computed per day, per hour or to the second, and does the new plan apply from the start of the upgrade day? - Can there be several upgrades in one period, and are downgrades allowed? - If the fee is charged in advance, is the unused part of the old plan credited on this invoice or on the next one? #### What This Part Should Cover - Splitting the period at each upgrade and pricing each piece - A stated proration and rounding rule, and its effect on the total - Validation: upgrades out of order, to a cheaper plan, or outside the period ### Part 3 — Usage and segmented billing Add usage-based charges. The report calls the pricing segmented billing: usage is split into bands, and each band has its own unit price. ```hint Work examples by hand first Price a few usage amounts by hand, including amounts exactly on a band boundary and zero usage, before writing the general rule. ``` #### Clarifying Questions for this Part - Is each band priced separately (the first units at the first price, the next units at the next price), or does the total usage fall into one band whose price applies to every unit? - Do the bands or the unit prices depend on the plan, and if so, how is usage priced in a period with an upgrade? - Can unit prices be fractions of a cent, and does usage arrive as a total or as individual events that may be repeated? #### What This Part Should Cover - Correct band arithmetic, including band boundaries and zero usage - Where usage charges are rounded relative to the unit prices - Line items that explain how the usage charge was computed ### What a Strong Answer Covers - Settles the input format, the money representation, proration and the band semantics before writing code - A model built around time segments and line items, so that each part adds code instead of rewriting earlier parts - Exact money arithmetic with one stated rounding rule - Correct proration at upgrades and correct band arithmetic - Tests for each part, including boundaries, and a check that earlier parts' results do not change ### Follow-up Questions - Add downgrades that take effect at the start of the next period. What changes in the model? - The bands differ by plan, and the customer upgrades partway through the period. How do you price that period's usage? - Usage arrives as individual events that the sender may retry. How do you avoid charging a retried event twice? - Prices change next month, and an invoice for a past period must be regenerated. How do you make sure it comes out the same?