Design Google Calendar
Problem Statement
Design a calendar application like Google Calendar, focusing on the client side. Users should be able to create and delete events, switch between multiple calendar views (day, week, month), create recurring events, and reschedule a single instance of a recurring event without touching the rest of the series. Assume the backend works; the interview evaluates the API contract you define, the component state model, and the data flow through the client.
This is a frontend-leaning Product Architecture prompt. The distributed-systems parts (storage, fan-out, notifications at scale) are explicitly out of scope. What makes it hard is recurrence: a weekly meeting is one record that represents infinitely many instances, and the moment a user drags one occurrence to a new time, your data model, API, and client cache all have to agree on what that means.
This walkthrough follows the Product Architecture framework: requirements, data model, API design, high-level client architecture, and product trade-offs.
The recurring-event requirement is the core of this question. Get the representation right early: a series is stored as a rule, instances are derived, and a rescheduled instance becomes an exception that overrides the rule for one occurrence. Every later phase builds on this.