Low Level Design: Calendar and Meeting Invite Service

Overview

A calendar and meeting invite service lets users create events, invite attendees, track RSVPs, and synchronize with external calendar clients. The core design challenges are recurring event expansion, timezone-aware storage, conflict detection, and bidirectional sync via CalDAV.

Event Schema

The central entity is the Event. Key fields:

• id — UUID primary key
• organizer_id — foreign key to users
• title — short display name
• description — optional long-form text
• location — free text or structured address
• start_utc / end_utc — datetimes stored in UTC
• original_timezone — IANA timezone string (e.g. America/New_York) for display
• recurrence_rule — RFC 5545 RRULE string (e.g. FREQ=WEEKLY;BYDAY=MO,WE,FR)
• recurrence_exceptions — array of UTC dates excluded from expansion
• status — ENUM('active','cancelled')
• created_at / updated_at — audit timestamps

A separate EventAttendee table links events to users: event_id, user_id, invite_status, responded_at.

Invite Attendee State Machine

Each attendee entry moves through a simple state machine:

• pending — invite sent, no response yet
• accepted — attendee confirmed
• declined — attendee rejected
• tentative — attendee is unsure

Transitions: pending → accepted, pending → declined, pending → tentative. Accepted and tentative can transition back to declined, and declined can be re-accepted. Every state change triggers a notification to the organizer and optionally to other attendees.

Recurring Event Expansion

Rather than storing every occurrence, recurring events store a single master record with an RRULE. Expansion is computed on read:

• Parse the RRULE using a library (e.g. python-dateutil or rrule.js)
• Generate occurrences within the requested date window
• Filter out any dates listed in recurrence_exceptions
• Apply the original_timezone for display, keeping all internal computation in UTC

When an attendee modifies a single occurrence (e.g. reschedules one Monday), store an EventOverride record with the master event_id, the original occurrence date, and the new start/end. This is the standard iCalendar RECURRENCE-ID pattern.

Conflict Detection

Before confirming an invite or creating an event, check the attendee calendar for overlapping events. Two events conflict when:

new.start_utc < existing.end_utc AND new.end_utc > existing.start_utc

Run this query against accepted and tentative events for the user. Return conflicts as warnings (soft block) rather than hard errors so users can override. For recurring events, expand the relevant window before checking.

Timezone-Aware Storage

Always store datetimes in UTC. Store the original_timezone separately so the UI can render events correctly in the creator’s and each attendee’s local time. When exporting to ICS, emit DTSTART with a TZID parameter to preserve intent. Never store local time as a naive datetime — this causes bugs around DST transitions.

ICS Export and CalDAV Sync

ICS export produces a static .ics file for one-time import into Apple Calendar, Outlook, or Google Calendar. Include VEVENT components with UID, DTSTART, DTEND, RRULE, SUMMARY, DESCRIPTION, ORGANIZER, and ATTENDEE fields. The UID maps to the event id.

CalDAV enables bidirectional sync. Expose a CalDAV endpoint per user calendar. Clients (e.g. Apple Calendar) issue REPORT requests to fetch changed events and PUT requests to push local changes. Use ETags and a sync-token (CTag) to minimize data transfer. Conflict resolution uses last-write-wins on updated_at, with a merge UI fallback for concurrent edits.

Notification Triggers

Emit notifications asynchronously via a message queue on these events:

• Invite sent — email to each attendee with accept/decline links
• RSVP change — notify organizer; optionally notify other attendees
• Event updated — notify all accepted/tentative attendees
• Event cancelled — notify all attendees regardless of status
• Reminder — configurable lead time (e.g. 15 min, 1 day) per attendee

Reminder scheduling: store a reminders table with event_id, user_id, remind_at (UTC). A worker polls for due reminders and dispatches push/email notifications, then deletes the row.

See also: Netflix Interview Guide 2026: Streaming Architecture, Recommendation Systems, and Engineering Excellence

See also: Atlassian Interview Guide

See also: Airbnb Interview Guide 2026: Search Systems, Trust and Safety, and Full-Stack Engineering