Design the event settings and conflict-handling system for a large-scale calendar product similar to Google Calendar. Users can create, update, and delete calendar events. An event may carry attendees, a start and end time, a time zone, recurrence rules, reminders, a visibility setting, a location, and a video-meeting link. The interview focuses especially on **how the system detects and handles conflicts** when a user creates or updates an event — including recurring events, multiple attendees, privacy, time zones, and concurrent edits. Walk through the data model, the conflict-detection path, and how the design holds up at scale. ```hint Where to start Ask what each part of the system is optimized for. The fields users edit (title, attendees, reminders, recurrence) and the data a conflict check actually needs (just time ranges) have very different access patterns. Decide whether one schema should serve both, or whether the read path deserves its own shape. ``` ```hint Frame the core check precisely "Conflict" reduces to a geometric question about two time ranges. Before you write any index, nail down the exact boundary rule: should two events that touch end-to-start be a conflict? Get the predicate and its inequalities right first — the indexing and complexity argument both fall out of how you've framed this. ``` ```hint Name the dimensions that make it hard This isn't one problem; it's several stacked on the interval check. Make sure you've identified each axis the interviewer will push on — an event that repeats forever, a viewer who shouldn't see another calendar's details, and two writers racing on the same calendar — and have a position on each. You don't need the final mechanism yet; you need to know these are the battlegrounds. ``` ```hint Be careful with time Decide what you store for time and why, then pressure-test it against a recurring meeting that crosses a clock change. Which representation do you compute overlap in, and which one do you trust to decide *when* the meeting "really" is? Getting these two roles confused is where subtle bugs live. ``` ### Constraints & Assumptions State your assumptions explicitly; reasonable numbers for a Google-Calendar-scale system: - **Scale:** on the order of $10^8$ active users and many events per user; a single popular calendar (a conference room, an exec) can hold thousands of events in a quarter. - **Read/write mix:** heavily read-skewed — free/busy lookups and conflict checks vastly outnumber writes. - **Latency:** a conflict check on event create/update should feel interactive — target tens of milliseconds for the common case (organizer + a handful of attendees). - **Availability/durability:** events must never be silently lost; high availability for reads. - **Conflict policy is configurable:** the product may `reject`, `warn` (require confirmation), or `allow override`. In consumer calendars double-booking is usually *allowed with a warning*, not hard-blocked. - **Free vs. busy:** only events marked busy / tentative / out-of-office affect availability; events marked *free* never create conflicts. - Exact numbers are negotiable — state your assumptions and design to the right order of magnitude. ### Clarifying Questions to Ask - Is double-booking allowed (warn-and-proceed) or must the system hard-block conflicts? Does it differ for the organizer vs. invited attendees? - For a multi-attendee event, do we block on *any* attendee's conflict, only required attendees, or only the organizer? - How far into the future must recurring-event conflict checks reach, and is there a bound on recurrence (e.g., "every weekday forever")? - What free/busy visibility do users get into calendars they don't own — full details, busy-only, or nothing? - How should tentative, free, and out-of-office events affect conflict detection — hard conflict, soft conflict, or ignored? - Do we need cross-organization / external-calendar (e.g. CalDAV / federated free-busy) interoperability, or only events inside our own system? ### What a Strong Answer Covers - **Requirements split** into functional (CRUD, recurrence, attendees, settings, conflict detection, suggestions, notifications) and non-functional (latency, availability, concurrency correctness, time-zone correctness, privacy). - **Data model** that separates a canonical event/attendee schema from a denormalized availability/free-busy index purpose-built for overlap queries. - **Conflict semantics:** the exact half-open overlap predicate, free vs. busy vs. tentative vs. out-of-office, all-day normalization, and back-to-back handling. - **Indexing choice** for overlap queries (sorted-interval table with a `(calendar_id, start)` index, interval tree, or windowed partitions) and a query/insert complexity argument. - **Recurrence handling** — RRULE storage, rolling materialization horizon, on-demand expansion, exception (this-occurrence / this-and-future / whole-series) handling, and per-occurrence conflict reporting. - **End-to-end create/update flow** including where the conflict check sits and how policy (reject / warn / override) is applied. - **Concurrency control** — optimistic versioning vs. per-calendar locking vs. reservation/TTL, with the tradeoffs spelled out. - **Privacy-aware conflict responses** — busy-only vs. full-detail based on ACLs, with private events surfaced as opaque busy blocks. - **Time-zone / DST correctness**, especially for recurring events. - **Consistency between the event store and the derived index** (transactional or outbox/CDC), plus index rebuild and async notifications. - **UX of conflicts** — return conflicting intervals and suggested alternative slots rather than a bare rejection. ### Follow-up Questions - How would you add **"find a time that works for all attendees"** (cross-calendar slot suggestion), and how does its cost scale with the number of required attendees and their time zones? - A user reports that a recurring meeting shows a conflict on **only some occurrences** after a DST change. Walk through how your recurrence + time-zone handling produces — or avoids — that bug. - How do you keep the denormalized availability index from drifting out of sync with the canonical event store, and how would you detect and repair drift? - How would the design change if double-booking were **strictly forbidden** for a class of resources (e.g. a conference room or a doctor's appointment slot) rather than advisory? Which concurrency strategy survives a burst of simultaneous bookings on one hot resource, and why do the others fall over?