System Design Interview
Calendar service inspired by Google Calendar and the iCalendar/CalDAV standards: recurrence rules expanded per view window, invites and RSVPs, scheduled reminders, incremental sync with sync tokens, and free/busy scheduling. A teaching design.
See why copying every occurrence of a recurring event breaks down.
What was missing: Nothing yet.
Why that's risky: A daily stand-up 'forever' needs endless rows, and changing its time means rewriting all of them; at the 9 am peak one database serves every view.
What gets added: One server that saves each occurrence of a recurring event as its own row and reads them back for the week view.
Trade-offs: Simple reads, but writes and storage explode with recurrence.
Store each series once and expand it only for the window being viewed.
What was missing: Recurring events were copied into a row per occurrence.
Why that's risky: Every view still expands rules from the primary database, and the morning peak is all reads.
What gets added: An event service that saves a series once as a recurrence rule (RRULE) with its time zone plus exception rows for edited or cancelled occurrences, and a view service that expands rules only for the requested day, week or month.
Trade-offs: Reads do a little computation (expanding rules) so writes and storage stay tiny.
Serve the 9 am rush of calendar views without loading the primary.
What was missing: Every view expanded rules from the primary database.
Why that's risky: Meetings with other people don't exist yet: no invites or RSVPs.
What gets added: A view cache of expanded occurrences per calendar and window, invalidated when the calendar changes, and a read replica behind it.
Trade-offs: A view may lag an edit by a moment until the cache is invalidated.
Put a meeting on every attendee's calendar and track their answers.
What was missing: No way to invite people or record their answers.
Why that's risky: Nobody gets reminded before a meeting starts.
What gets added: An invite service that adds attendees, records RSVPs and places the event on each attendee's calendar, plus an email queue and sender that send invitations with .ics attachments for people on other calendar systems.
Trade-offs: Attendees see the invite on their calendar at once; the email arrives seconds later.
Fire reminders on time for every occurrence, including recurring ones.
What was missing: Nothing sent reminders.
Why that's risky: Phones and desktop apps re-download whole calendars to stay in sync, and scheduling across people needs everyone's free time.
What gets added: A reminder schedule of delayed jobs keyed by fire time (upcoming occurrences are expanded a day ahead), and reminder senders that push and email each attendee when a job comes due.
Trade-offs: Scheduling a day ahead means a change made seconds before a reminder must also update its job.
Sync devices incrementally, find common free time, and protect the service.
What was missing: Devices re-downloaded whole calendars, finding a meeting time meant opening everyone's calendar, and nothing limited buggy clients.
Why that's risky: Remaining risk is regional: calendars must be served from a nearby region and fail over.
What gets added: A per-calendar change log with sync tokens so apps fetch only what changed, a free/busy service and index of busy blocks for scheduling, a rate limiter, and monitoring of view latency, reminder lateness and sync lag.
Trade-offs: The change log costs an extra write per change in exchange for tiny sync responses.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
