Schedule Welcome and Expiration Emails from Subscription Records

A subscription service sends automated emails at set points in each customer's subscription, such as a **welcome** email when the subscription starts and an **expiration** email when it expires. Write a program that takes the customers' subscription records and produces every email that must be sent, in the order the emails will go out. Assume each record gives a customer name, the subscription start date, and the subscription length in days. The interviewer supplies the real input format. The output is a list of `(send date, email type, customer)` entries sorted by send date. For example (illustrative values), a customer whose 30-day subscription starts on March 1 gets a welcome email on March 1 and an expiration email on March 31. ```hint Turn records into dated events Think of each subscription as producing a small set of dated events, and ask what single ordering over all customers' events gives the required output. ``` ```hint Keep the email rules out of the loop More email types are likely to be added once the first version works. Consider how to describe "which email, relative to which moment" so that adding a new type is a data change rather than new control flow. ``` ### Constraints and Clarifications - Assume a subscription expires on its start date plus its length in days. - Dates are calendar dates. Use a date library for the arithmetic rather than hand-rolled day counting. ### Clarifying Questions - Which email types exist besides welcome and expiration, and when is each one sent relative to the start or the end? For example, is there a reminder before expiry? - How should emails with the same send date be ordered: by email type, by customer, or by input order? - Can a subscription change (renew, upgrade, cancel) after it starts? If so, how is that change given to the program? - Should the program print the schedule, return it, or actually send each email at the right time? ### What a Strong Answer Covers - Correct send dates, including across month and year boundaries - A deterministic order, with an explicit tie rule for emails on the same date - A representation of email rules that makes adding a new email type cheap - Clear handling of degenerate subscriptions, such as a length of zero days - Complexity for n customers and a small set of rules, plus a few focused tests ### Follow-up Questions - Add a reminder email a configurable number of days before expiration. What changes, and what should happen when the subscription is shorter than that notice period? - Customers can now change plans or renew partway through. How do you cancel or reschedule emails that were already planned? - Subscription events now arrive over time instead of as a batch, and each email must go out at its send time. How would you structure the scheduler, and how would you avoid sending an email twice after a crash?