Collaboration
Calendar scheduling - a time that suits five people
Why a meeting time is computed from rules and guesses rather than read from a table, and what that costs.
What this board gets wrong on purpose
The tension
Every free/busy answer here is a cached, rounded, deliberately vague reply from a system this one does not control - opaque blocks with no titles, half-hour granularity, a short horizon, a fifteen-minute TTL and a sizeable share of lookups that simply fail. The board then presents the intersection as though it were a fact, and there is no reservation anywhere: two organisers scheduling at the same moment will both be offered the same slot and both will take it, with the collision surfacing later as an RSVP. Treating an unknown as free is what makes that happen and treating it as busy makes the product useless, so the board treats it as free and says so here. Underneath, tzdata is versioned state baked into every binary: when a government moves a DST boundary, every materialised UTC instant is wrong until a re-expansion job has run, and any service still holding the old rules disagrees with the ones that have upgraded - which shows up as reminders an hour early for a fraction of users and as nothing at all in any error rate.
Requirements
Ask these before drawing anything
- Is a recurring event one thing or many? One row with a rule is the only affordable answer, and it means every read does work and every exception is a patch.
- Does "09:00 every weekday" mean the same wall clock or the same instant? Wall clock, always, for a recurring meeting - which means its UTC time moves twice a year and the stored instant is a cache, not the truth.
- What happens to a recurring meeting at 02:30 on the morning the clocks go forward, when 02:30 does not exist? Pick a rule, write it down, and apply it in exactly one place.
- Can an external organisation see whether we are busy, and at what granularity? The answer is a policy decision with an architecture attached - opaque blocks, coarse rounding, and a short horizon are all deliberate.
- Is a proposed time held while the organiser decides? Almost no calendar system does this, so two organisers can and will take the same slot. Decide whether you are fixing that or accepting it.
- What does an unanswerable free/busy lookup mean - free or busy? Free books over people. Busy makes the product useless. There is no correct answer, only a chosen one that has to be visible.
- How far ahead may anyone schedule? It bounds recurrence expansion, which is the hottest operation in the system.
- Do we have to interoperate over iCalendar and iTIP? If yes, a large share of the semantics is decided by a specification from 1998 rather than by this design.
Functional
- Create a one-off or recurring event, with attendees, in a named time zone.
- Edit or cancel a single occurrence of a series, or this-and-all-following, without disturbing the rest.
- Find candidate times for N people over a window, respecting each person’s working hours in their own zone.
- Read free/busy for people in other organisations, at whatever granularity they will give.
- Track per-attendee responses, and show the organiser who has not replied.
- Fire reminders at the right local time, exactly once, per attendee preference.
Non-functional
- Render a month of a calendar with 180 recurring series: p95 under 400 ms.
- Suggest times for 5 attendees over 14 days: p95 under 1.2 s, including external lookups, with a hard 800 ms budget on each external call and an explicit "unknown" when it is exceeded.
- A reminder fires once. Not twice, which is worse than not at all, and not an hour out.
- Instance identity is stable: an occurrence keeps its identity across edits to the series, because attendee responses and reminders are attached to it.
- 99.95% for reading a calendar. Free/busy for external domains has no availability target at all, because it is not this system.
Out of scope
- Room and resource booking, which needs actual reservation semantics and is therefore a different board.
- Video conferencing links, which are an attachment.
- Travel-time and location awareness.
The rest of this board
Available on Tier Slate
This page publishes the question. The answer — 5 more written pages, a 9-step narrated walkthrough and a 5-table schema — is the board itself, and it opens in Tierslate.
- 5written pages
- 9walkthrough steps
- 5tables42 columns
5 pages behind this one
- Capacity estimation
- Storage estimation
- Availability
- How it works
- Deployment plan
More boards
Several people editing one thing without losing an edit.