Design the availability engine behind a team calendar: the service that answers "when is everyone free?" It powers the free/busy bars you see when inviting people and the "suggested times" a scheduler proposes for a meeting.

Operating context. Users own calendars full of events — one-off and recurring, in many time zones, with working-hours windows. A caller asks for the busy intervals of a set of attendees over a window, or asks for the earliest open slots of a given duration that work for everyone invited. Monday mornings are brutal: everyone opens their week at once. A user who just edited their own calendar must see the change reflected immediately, while everyone else can tolerate a few seconds of lag.

Out of scope. Event creation and editing UX, meeting-room and resource booking, external-calendar federation (importing a third-party calendar), and notification/RSVP flows. Assume events already exist in a store you control.

What to produce. A high-level architecture covering: how you represent and merge free/busy intervals with working hours and time zones; how you expand recurring events without materializing unbounded instances; the event store and its partitioning; the slot-finding path that intersects many attendees at once; and the caching and freshness story that keeps availability fresh after a write without double-booking. Sketch the components and the flow of a 50-attendee "find a time" query; we will probe specifics in checkpoints.