Section 12: Doors Left Unlocked - Follow-up Feature Evolution

Executive Summary: The interviewer turns product manager with a roadmap: public booking pages, out-of-office, Exchange interop, AI scheduling, time insights, and attachments. A Staff candidate doesn't design six new systems. Each feature gets four questions: which seam, what's new, what it costs, and which named flip trigger it fires. Five arrive through open doors: the change stream, the room-booking saga, free/busy, and the ACL and RSVP paths. Booking pages force one real change, the first unauthenticated read path. We close with expand-migrate-contract, carried by versioned sync tokens.

Interviewer: "It shipped and it held. Product wants public booking pages, out-of-office, Outlook interop, an AI that finds the best time, 'hours in meetings' insights, and attachments. What does this do to your design?"

You: "Less than it sounds. For each one I'll name the seam it plugs into and whether it fires a flip trigger we wrote down. If a feature fits no seam, it's a new system, and I'll say so."

Key Insight: None of these was built early. Each fits because an earlier decision, made for its own reasons, left a clean seam and often a recorded flip trigger. Not blocking the future is cheap; building it speculatively is usually waste.

Booking Pages: The Saga Reused, and the One Real Change

Priya wants a public page where candidates book 30-minute interviews with her.

The write half is already built. Booking a slot is the problem Section 10 solved for NYC-12-Hudson: "no accepted event overlaps [start, end)" as a conditional write inside one partition. Now the partition is Priya's calendar, so her partition is the lock. The flow is hold-then-confirm: the visitor picks a slot, a hold row with a short TTL is written conditionally, the visitor confirms, and the hold becomes an event that fans out and schedules reminders through the outbox like any create. Two visitors racing for Tuesday 10:00 serialize in her partition. One wins, and the other hears "just taken" within the same p99 ≤ 2 s as a room booking. One honest difference from a room: her partition serializes bookings, but invitations reach it by async fan-out and big-group events are merged on read. So the hold's overlap check also reads her large-group events, and a booking can still collide with an invite a few seconds in flight: a rare, resolvable conflict for a person, a double-booking for a room, which is why rooms take no fan-out writes.

The read half is new. Every read path so far is authenticated: free/busy answers a signed-in caller with the freeBusyReader role. A booking page answers anyone, bots included. Reusing the free/busy endpoint is the rejected alternative. It would put anonymous load on a path sized for ~3.5K/s peak at a 500 ms p99, and a scraper querying arbitrary windows learns the shape of Priya's whole schedule. So the page gets its own path. It returns open slots, never busy intervals, only inside the page's configured window. Slots are cached per page, invalidated by her change-log seq, and served behind per-IP and per-page rate limits.

Interviewer: "What would make you change the booking write?"

You: "The flip trigger Section 10 named for rooms. Once a booking must be atomic with something else, like a paid consultation that charges a card, I'd pay for a real multi-partition transaction."

Quick check before moving on: