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.

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.

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.

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