Meeting Scheduler

The problem

"Design a meeting scheduler." Ana wants 30 minutes next week with five colleagues in three cities, and the scheduler should find a time when all six are free and at work. People also publish booking links, like Calendly's: a page of open slots where a guest takes one.

This practice problem reuses the pattern of Design Ticketmaster, applied to people's time: a slot only one can have is taken in one step that checks and writes. Repeating meetings come from Calendar Invites, as a rule expanded for the week being searched. What's new: a common free time across time zones and working hours, sharing busy times without the details, two organizers booking the same person at once, and booking links. Park polls and video calls.

The numbers

Each of the 6 people has about 20 meetings next week: 6 × 20 = 120 busy intervals. Hours outside work count as busy too, one block before Monday, one for each of the four nights and one after Friday, so 36 more, 156 in all. Sorting and merging that takes microseconds, so every search runs on demand with nothing precomputed. The slow part is reading six calendars, so read them in parallel.

Finding the free time

Say Monday has no gap. Here is Tuesday, Oct 27, 2026, with everyone working 9:00 to 17:00 local time:

who   city        busy (local)   busy (UTC)
Ana   New York    9:00–9:30      13:00–13:30
Ben   New York    11:00–12:00    15:00–16:00
Cy    London      13:15–14:00    13:15–14:00
Dee   London      10:00–11:00    10:00–11:00
Eli   Bucharest   9:00–10:00     7:00–8:00
Fay   Bucharest   16:30–17:00    14:30–15:00

1. Read the six people's busy times for the week.
2. Turn each time into UTC by its owner's time zone, and add the hours outside work as busy. In UTC, Ana and Ben work 13:00–21:00, Cy and Dee 9:00–17:00, Eli and Fay 7:00–15:00.
3. Sort all the busy intervals by start time.
4. Merge intervals that overlap or touch: Tuesday becomes busy 0:00–14:00 and 14:30–24:00.
5. Scan the gaps for the first of 30 minutes or more: 14:00–14:30 UTC, which is 10:00 in New York, 14:00 in London and 16:00 in Bucharest.

The merge is the classic merge-intervals coding problem. Use each person's time zone, such as America/New_York, never a fixed offset: that week Europe has moved its clocks back and the US hasn't yet, so New York is 4 hours behind London instead of the usual 5. With a fixed 5 hours, Ana's 9:00 meeting would land on 14:00 UTC, and Tuesday would show no slot at all.

GET /free-time?people=ana,ben,cy,dee,eli,fay&minutes=30&week=2026-10-26
  → 200 OK   {"slots": [{"start": "2026-10-27T14:00Z", "end": "2026-10-27T14:30Z"}, …]}

Free/busy only

To search, the scheduler needs Cy's Tuesday, and her 13:15 is a dentist appointment. It reads free/busy: the start and end of each busy block, with her time zone and working hours. The title, the place, the other guests and her notes stay in her calendar for the people she shares them with; a title alone can say far more than "busy". Free/busy is also small, a few bytes per meeting.

Two organizers, one slot

Ana and Ben both find Cy free on Tuesday at 14:00 UTC, both want the room Orion, and both press Send in the same second. The rule: people can double-book; rooms can't.

• Cy: both invites go out, Ben's marked as a clash with Ana's meeting, and Cy chooses. A tentative hold on her time would let whoever searches first block anyone's calendar, though Cy hasn't accepted yet and people double-book on purpose.
• Orion: a room is a seat. Book it with Ticketmaster's conditional update, which sets the room's 14:00 only if it's still free: the first update wins, and the other organizer gets "room taken" at once.

UPDATE room_slots SET meeting = 'm1'
WHERE room = 'orion' AND start = '2026-10-27T14:00Z' AND meeting IS NULL

Searching again just before sending doesn't help: both searches can still run in the same second and see Orion free.

Booking links

Ana publishes a link with 30-minute slots on Tuesday from 15:00 to 17:00 New York time: 15:00, 15:30, 16:00 and 16:30. The page shows the open slots from her free/busy minus her bookings. Gus and Hal click 15:30 in the same second.

A booking is a conditional insert into a bookings table with a unique key on (host, slot start). Gus's insert lands first; Hal's breaks the key and fails, and his page shows the slots still open. Reading Ana's calendar and then saving leaves the check-then-act gap: both reads see 15:30 free, and both save. No hold is needed: holds cover minutes of paying, booking is one click, and holding a slot for everyone who opens the page would let 4 visitors hide all 4 slots. With slots of mixed lengths, a unique start isn't enough; lock the host's row while checking for overlaps.

POST /links/ana-30/bookings   {"start": "2026-10-27T19:30Z", "email": "gus@…"}
  → 201 Created   {"booking": "b7"}
  → 409 Conflict  if the slot was just taken

Same pattern as Ticketmaster

A slot only one can have, a room or a booking link's slot, is a seat: one step that checks and writes, and the loser is told at once. People aren't seats: their time is never locked, only shown as busy, and only free/busy is shared.

Summary

• Scope: find a time for many people; booking links; repeats as in Calendar Invites.
• Numbers: about 120 busy intervals a search, 156 with nights, computed on demand.
• Free time: every interval in UTC by its owner's zone, hours outside work as busy, sorted, merged, the first 30-minute gap.
• Privacy: free/busy only, never titles.
• Two organizers: people can double-book, rooms can't.
• Booking links: a conditional insert on host and slot.