Katkat
Back

Design Calendar Event Conflict Handling

GoogleSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question evaluates a candidate's competence in designing scalable calendar event and conflict-handling systems, focusing on data modeling, time semantics (time zones and recurrence), concurrency control, and distributed-system trade-offs, and falls under the System Design domain.

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.

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?

Hints

Hint 1

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 2

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 3

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 4

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.

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?