Design a Service That Finds Common Free Time Across Connected Calendars

Design a calendar availability service. Given a set of people and a time window, it answers when they are free, so that the product can propose meeting times for a group or let someone book time with a person. Users' calendars are kept in external calendar providers that they connect to your product. The source gives only the name of this prompt, so its scope is stated below as assumptions to confirm with the interviewer. ### Constraints and Clarifications - Assume users connect one or more calendars from external providers such as Google Calendar or Microsoft Outlook; whether the service also hosts its own native calendars is a clarifying question. - A query supplies participants, a time window and a meeting duration, and returns candidate time slots in which every required participant is free. - Users have working hours in their own time zones, and availability must respect them. - Whether the service also books the chosen slot and writes the event back to the participants' calendars is left to clarify; the design should say what changes if it does. ### Clarifying Questions - Is this for scheduling among colleagues, for a public booking page where outsiders pick a time with a user, or both? - How fresh must availability be after someone changes an event in their provider's calendar? - Should tentative events, all-day events and declined invitations count as busy? - Must the service create the event and guarantee that a slot cannot be booked twice? ### Part 1 — Computing common free time Define how busy time, working hours and time zones are represented, and give an algorithm that finds slots of a given length in which all required participants are free within a window. State its complexity. ```hint Combine busy time It is often easier to merge everyone's busy periods and look at the gaps than to intersect everyone's free periods. ``` #### What This Part Should Cover - A single, unambiguous time representation and correct handling of time zones and daylight saving - Merging busy intervals across participants and turning gaps into slots - Working hours, buffers, recurring events and optional attendees - Complexity and a worked example ### Part 2 — Keeping availability fresh Explain how the service learns about events in external calendars and keeps its view current, within provider rate limits and when providers or credentials fail. ```hint Cost of asking live Calling every participant's provider on every query is the simplest design. Estimate what it costs at scale and where it stops working. ``` #### What This Part Should Cover - Live lookups versus a synchronized local copy, and the choice made - Initial sync, change notifications and incremental updates - Staleness bounds, rate limits and credential failures - Storing only what availability needs ### Part 3 — Booking without double-booking, and scale Two people try to book the same slot with the same host at the same moment. Explain how the service prevents a double booking, keeps the host's external calendar consistent, and scales to many users and busy booking pages. ```hint Shown is not promised The availability displayed a moment ago is only a hint. Decide where the final, authoritative check happens. ``` #### What This Part Should Cover - An atomic reservation step that rejects overlapping bookings - Writing events back to providers reliably and reconciling conflicts - Partitioning and caching for queries and booking pages - Behavior when a provider is unavailable ### What a Strong Answer Covers - A correct availability algorithm with explicit time-zone handling - A sync design whose freshness, cost and failure behavior are stated - A booking path whose correctness does not depend on the cached view being fresh - Privacy: others see free and busy time, not event details, unless permitted - Observability of sync lag and booking conflicts ### Follow-up Questions - How would you rank candidate slots rather than return all of them? - How would you find a weekly time that is free for a recurring meeting over the next three months? - How do you handle a participant whose provider has been unreachable for an hour? - How would you support round-robin booking across a team of hosts?