Before diving into design, we estimate the scale to guide our choices:

• User Base: Assume 100 million active users. Not all will use the calendar daily; suppose around 10–20% (10–20 million) are daily active users who open the calendar or get notifications each day. Peak concurrent users might be tens of millions globally. This is a very large-scale system by any measure.
• Event Volume: Let’s estimate how many events might be created or updated. If 10% of users create events on a given day and each such active user schedules ~5 events on average, that’s about 50 million new events per day. This is on the higher end; even a more conservative estimate (say 10 million events/day) is huge. For 50M events/day, that’s roughly ~600 events/second on average, with peaks potentially several times higher (a peak of 2,000–5,000 events/sec during busy hours). Over a year, 50M/day leads to ~18 billion events. Each event may generate additional write operations (invitations, RSVP updates), so write throughput must handle bursts.
• Read Operations: Reads (viewing calendars, checking availability) will far exceed writes. Each daily active user might view their calendar a few times a day, resulting in perhaps 100–200 million read requests per day across the user base (e.g. ~2 reads/user/day for 50M users). That’s on the order of 1,000–2,000 reads/second average, with higher bursts. Additionally, real-time sync (push updates) can reduce the need for clients to poll frequently, but initial loads and some polling will happen. We should design for a read-to-write ratio possibly around 10:1 or more.
• Storage Needs: Storing events persistently requires significant space. If each event with its metadata and invite list is about ~1 KB in size (just an estimate for a basic event record), 50 million events/day would consume ~50 GB of storage per day. Over one year that’s on the order of 20 TB of data per year just for events. In practice, events with long descriptions or many attendees can be larger, and we also store user info, room info, indexes, etc., but we will compress or partition data as needed. We must plan for petabyte-scale storage over years or prune older data if necessary.
• Bandwidth: Each event or calendar view response might be a few KB (especially if returning a list of events). So serving, say, 100M reads/day at a few KB each implies hundreds of GBs of data transfer per day. This is manageable at the cloud infrastructure level but underscores the need for efficient data encoding and possibly compression for responses.
• QPS (Queries Per Second): Summarizing the above – we might expect on the order of few thousands of writes/sec and maybe 5–10k reads/sec at peak globally. This necessitates load balancing and distribution across many servers. The system’s design should comfortably handle these magnitudes with room to grow (e.g. 10× growth to billions of events per day).

These estimations guide us to choose a distributed, scalable architecture with careful consideration for database sharding, caching, and load balancing.

In this section, we will dig deeper into how each component handles the core features (event lifecycle, invitations, room booking, etc.).

Event Lifecycle Management

Managing events involves creating new events, updating them, handling recurring events, and deleting/cancelling events. It also involves the invite/response workflow. Here’s how the system handles these:

• Event Creation (Scheduling a Meeting): When a user creates an event, the Event Service performs several steps:

  1. Validation & Conflict Check: It checks that the input data is valid (times, etc.) and optionally ensures the event doesn’t conflict with an existing event in the user’s calendar (unless double-booking is allowed). If the user added other attendees or selected a room, the service uses the Availability Engine to verify those people and the room are free at the chosen time. If there’s a conflict (someone is busy or the room is taken), it returns an error or suggests alternatives (e.g., different time or another room).
  2. Event Persistence: Once validated, the service creates a new event entry in the database. It generates a unique event_id (e.g., a UUID or a combination of shard ID and an auto-increment). It writes the event data to the Events table (on the appropriate shard). If using a SQL database, this might be a transaction that also inserts invitee rows in the Invitations table. If using an eventually consistent store, it might first write the event, then separately fan out invitations. Either way, each invitee will have an entry indicating they have a new invitation.
  3. Invite Notifications: After saving, the Event Service enqueues messages for each invited user (except perhaps the organizer themself). The Notification Service will send out invitations – often via email (with an .ics calendar attachment) and via push notification to any of the invitee’s active devices. This notifies them in real-time that a new event is awaiting their response.
  4. Room Booking: If a room was specified, the system marks that room as booked at that time. This could mean creating an entry in the Room’s calendar (essentially treating the room as an attendee) or updating a room schedule. The booking is done atomically with event creation to avoid race conditions (we wouldn’t want two events booking the same room simultaneously). If two users happen to try booking the last available room at the same time, one transaction will succeed and the other will detect the room is now busy and fail or need to suggest a different room.

  The result of event creation is that the organizer’s calendar now has the event (marked maybe as busy time), each invitee’s calendar shows a tentative event (awaiting their action), and the room’s calendar shows it reserved. All these entries are linked to the same event object, so they stay in sync on updates. The system’s response confirms creation, and clients will soon reflect the new event (often via push update as well as the immediate response).

• Invitations and RSVP Handling: Invitees will respond to invitations in their own client (accept, decline, etc.). When an invitee responds, the client sends an update (e.g. “User X accepted event Y”). The Event Service updates the Invitations table for that event (setting the status to Accepted and noting the response timestamp). It may also increment a count of accepted vs declined for quick viewing. If the attendee accepted, their calendar entry might now be marked confirmed; if declined, they might choose to remove it from their view. The service could send a notification to the organizer (or update the event data) so the organizer sees that response (e.g., “Alice accepted”). This invite response update needs to be propagated to all relevant views (the organizer’s list of attendees should show Alice as accepted now). Typically, this is a lightweight write that is easy to handle. For large meetings, a pattern to reduce load is to not notify all attendees of each response (could get noisy), just update the organizer’s copy and each individual’s status. The system could allow each user to see who’s coming by checking the event’s attendee list on demand. Consistency: Because multiple people are involved, we lean towards eventual consistency for invitations – for instance, if an invitee in a different region responds, the organizer’s view might update a few seconds later once the data replicates or a push notification is delivered. We ensure no data is lost (durable storage), but slight delays in reflecting the latest RSVP to everyone are acceptable in exchange for performance.

• Event Updates: When the organizer (or someone with edit rights) updates an event’s details (time change, adding/removing attendees, changing the room, etc.), the system needs to propagate this to all participants. The update flow is similar to creation: the Event Service writes the updated fields to the event record (and possibly marks the old instance as changed or keeps a history of changes). Then it notifies attendees of the changes. For example, if the time changed, it might send an update notification: “Meeting moved to 4pm.” On the backend, we might treat this as a new version of the event. We could include a version number or timestamp in the event record for concurrency control. If an invitee had declined the original invite, we still notify them of the change in case they might attend the new time. Handling updates to recurring events can be complex – e.g., changing “all future events” in a series versus one occurrence (we handle recurring specifics below). Importantly, updates must be atomic relative to the event data: all users should eventually see the same updated details. During the update, we might lock the event or use a compare-and-swap with version to avoid race conditions (if two editors try to modify at once). In case of conflict (two people edit at once), one update might win (based on timestamp or an organizer’s changes overriding attendees’ changes if attendees can edit some fields) – we’ll discuss conflict resolution later, but often the latest edit wins policy is used. Once updated, caches are invalidated and new data is served on subsequent reads. Attendees get a push notification or email about the changes.

• Recurring Events Management: Recurring (repeating) events pose special challenges. We have to support events that repeat daily, weekly, monthly, etc., possibly indefinitely. Storing every occurrence as separate events would be extremely inefficient (and potentially infinite for no end date). Instead, we use a recurrence rule approach:

  • We store a base event with a recurrence rule (e.g., “repeats every Monday until Dec 31, 2025”). This base event acts like a template. We do not pre-create all occurrences in the DB.
  • When a client requests to view events, the service will generate the occurrences on the fly for the relevant date range. For example, if you open your calendar for next week, the service sees you have an event with a weekly rule and will compute the specific dates (e.g. 7th June, 14th June, etc.) that fall into the view. It can return those as if they were normal events. This computation can be done in memory or via a helper function using the rule.
  • If the user needs to modify one occurrence or cancel one instance, we create an exception record. For example, if a meeting on one particular date is cancelled or moved, we store an override for that date (like “the event on 2025-06-14 is cancelled” or “moved to 4pm just for that day”). These exceptions ensure we don’t show an event on that date or adjust it accordingly. Exceptions can be stored in a separate table referencing the recurring event ID and the date of exception.
  • This way, recurring events are managed by storing one record plus any deviations. It saves space and avoids heavy writes. A background job might generate the next X occurrences for quick querying if needed (some systems generate a rolling window of occurrences, say a year ahead, and prune behind, to allow searching occurrences in the DB).
  • When editing recurring events, the system will ask if the change applies to one occurrence or the entire series (or series going forward). If it’s the entire series, we update the rule or base event. If it’s a single occurrence, we create an exception (or separate that one into a standalone event if completely changed). We ensure that past events remain unchanged in history (changes to a series usually don’t retroactively alter past instances once they’ve occurred, per typical calendar behavior).
  • Overall, the data model for recurrence might include fields for recurrence pattern and a link to a “series Id”, plus an exceptions table. This design allows infinite or long-running recurring events without blowing up storage, at the cost of on-the-fly computation.

• Event Cancellation/Deletion: When an organizer deletes an event (or cancels a meeting), the system will remove it from all participants’ calendars. Implementation-wise, we could soft-delete (mark as cancelled) in the DB to keep a record, or hard delete the records. Typically, we mark it cancelled and maybe keep it for a while for reference or in case of undo. All invitees are notified of cancellation (e.g., “Meeting at 3pm has been cancelled”). If this is a recurring event, we ask if they’re cancelling one occurrence or the whole series. That is handled accordingly (an exception if one instance, or removal of all future instances). The room booking, if any, is freed up. We again propagate notifications and update the data consistently.

Availability and Meeting Room Suggestions

One of the key features is helping users schedule meetings at a time and place that works for everyone. This is handled by the Availability Engine and related logic:

• Free/Busy Calculation: Each user (and each room) can be considered to have a free/busy schedule – periods when they are busy (have events) and free gaps in between. The system can calculate free/busy information by looking at a user’s events for a range. For instance, to find if Alice is free from 2-3pm, we check if any event on Alice’s calendar overlaps that interval. Doing this on the fly for many users could be expensive, so we optimize it. We maintain indexes on events by time; for example, an event table indexed by start_time and end_time can quickly retrieve events in a given range. If using a relational DB, a query like “SELECT events WHERE user_id = X AND start_time < query_end AND end_time > query_start” gives events that overlap a interval. If none are returned, the user is free. We may also precompute each user’s busy slots for the next few days into an in-memory structure for very fast answers (e.g., Interval Tree: A data structure optimized for querying overlapping intervals). Some systems periodically compute “free/busy blocks” for each user and store that summary separately (especially if integrating with external systems). For our design, a well-indexed event store per user may suffice, potentially cached.

• Finding Common Free Time: When scheduling with multiple attendees, the engine needs to find a time where everyone is free. A naive approach is to get each person’s busy slots and then find an intersection of free intervals. If there are N attendees, we intersect N lists of busy times to find a gap. This can be done in memory fairly quickly if each has a small number of events in the range. For many people with busy calendars, this could be heavier, but typically N isn’t huge (meetings of 5-10 people). We can optimize by prioritizing likely slots (during work hours, etc.). The Availability Engine might also use a search approach: iterate through time slots in the desired range (say the next week) and check each for availability of all. But an efficient intersection of intervals is usually enough.

• Room Availability: Rooms are treated similar to users in terms of availability. To suggest available meeting rooms, we consider the meeting time (or possible times) and the required capacity/location. The flow might be: user picks a time and attendees, and asks for a room suggestion. The system knows how many people (attendees count) and maybe the preferred location (e.g., “office location = London”). The Room database filters rooms that meet criteria (capacity >= number of people, and correct location or equipment if needed). For those candidate rooms, we check each room’s calendar for that time slot. The first few that are free can be suggested. Because there may be many rooms, we likely index rooms by building and capacity, and we might also maintain a quick lookup of next free slot for each room. However, simply querying each candidate room’s events in that time range is fine if the number of candidate rooms is reasonable. If there are hundreds of rooms, we can optimize by maintaining an inverted index of times -> free rooms. For example, each room could publish its free slots to an index that can be searched. But that might be over-engineering; often querying sequentially is acceptable given typical constraints (like specifying a building or floor).

• Caching Free/Busy Data: To reduce repetitive computation, the service can cache recent free/busy results. For example, if you are repeatedly scheduling with the same team, their free/busy for today might be cached. We must invalidate these caches on any new event that affects availability (e.g., someone just booked a slot we thought was free). We can also push free/busy updates via the Notification Service to the cache if a user’s schedule changes. This ensures room suggestions and availability queries use up-to-date info.

• Conflict Prevention: The system itself should prevent obvious conflicts: if a user tries to accept two overlapping events, it should at least warn them or mark one as conflicting. For rooms, the system must enforce exclusive booking – this is handled by transactions or row locks when inserting a room booking. On the UI side, highlighting conflicts on the calendar view helps users manage their availability.

Notification and Reminder Delivery

The Notification Service ensures users are kept informed of invites and upcoming events. Key points in this component:

• Invitation Notifications: As described earlier, when a new event with invitees is created, notifications are sent. Typically, an email invitation is sent to each external email address with the event details and links to respond. Internally (in-app), the user’s calendar view will show a new invite, and a push notification can alert them on their phone. We integrate with email servers (SMTP or services like SendGrid) for email delivery and with mobile push services (APNs for iOS, FCM for Android) for device notifications. The content includes event info and options to respond.

• Reminders: Users often set reminders (default or custom) for events (e.g., a notification 10 minutes before start). The Notification Service can schedule these. Implementation: when an event is created or when a user adds a reminder, the service calculates the reminder time (event start minus 10m) and either stores this in a scheduler or uses a distributed task scheduler (like a cron service or delayed job queue). At the appropriate time, a task will fire to send the reminder (again via push notification, email, or even SMS depending on user settings). To scale this for millions of events, we might use a message queue where messages are delayed until the reminder time, or a time-wheel scheduler service. Many systems also simply calculate upcoming reminders every minute: e.g., every minute look at events starting in 10 minutes and send notifications. With efficient indexing by start_time, we can fetch events in [now+9min, now+11min] and process them.

• Updates/Cancellations: Notifications are also used for event updates (e.g., “Meeting time changed”) and cancellations (“Meeting cancelled”). The service listens for these events (from the queue or event service) and sends out appropriate messages to attendees.

• Real-Time Updates: In addition to explicit notifications, our system supports real-time sync. We might use WebSockets or long polling from the client to get instant updates. When an event is created or updated, the Event Service can immediately push that update to all clients currently viewing that calendar (through a publish/subscribe system). For mobile, we often rely on push notifications as a trigger for the app to fetch new data (to save battery). Web clients might use a WebSocket connection to receive events. This ensures, for example, if two users are looking at a shared calendar and one adds an event, the other sees it appear within a second.

The Notification system is crucial for a “real-time feel” and to keep users engaged and informed without requiring them to constantly refresh.

Timezone Handling

Timezone support is a critical aspect of a global calendar. The challenges are: storing times in a consistent format, displaying in the user’s local timezone, and handling daylight savings changes.

• Standard Storage (UTC): The system will store all event timestamps in a canonical form, typically UTC. For example, if an event is created for 3:00 PM Pacific Time, which is 22:00 UTC, we store 22:00 UTC in the database along with a note that the event’s timezone is "America/Los_Angeles". Storing in UTC avoids ambiguity and makes comparisons easier. The event record can have a timezone field or offset for reference (especially important for recurring events, where “every day at 9 AM Eastern” needs to respect DST changes – storing the timezone ID allows correct generation of occurrences).
• User Timezone Preferences: Each user’s profile stores their current timezone (which they can change if they travel). When an event is displayed to a user, the client or server will convert the UTC time to that user’s timezone. For invites, each attendee effectively sees the event in their own local time. For example, a meeting stored at 22:00 UTC with timezone info might show as 3:00 PM for a Pacific user and 6:00 PM for an Eastern user, automatically adjusted.
• Daylight Savings and Shifts: By storing the timezone ID (e.g., "Europe/London") with events or with recurrence rules, the system can handle daylight savings. E.g., a recurring meeting at 9 AM London time will shift in UTC when DST changes, but because we know it’s "Europe/London", we generate correct times. We rely on a timezone library (like IANA tz database) to calculate offsets for future dates, as DST rules can change over years.
• Scheduling Across Timezones: If someone in New York schedules a meeting at 5 PM their time with a colleague in India, the colleague should see it as say 2:30 AM their time (perhaps not ideal – the availability system should consider work hours!). The system can optionally assist by showing the organizer what the local time for invitees will be, to avoid scheduling at odd hours. That kind of feature might require knowledge of user’s locale or working hour preferences.
• Edge Cases: If a user travels and updates their timezone, existing events created in the old timezone remain at their scheduled absolute time (e.g., a 9 AM meeting in NY will show as 6 AM if the user flies to California, because it’s still 9 AM Eastern event). This is expected behavior. We just ensure new events are created with the correct timezone context.
• Backend Processing: All backend scheduling (like reminders) operate in absolute times (UTC timestamps). So a reminder at “10 minutes before 9 AM Eastern” is actually “10 minutes before 14:00 UTC” (if DST off) or 13:00 UTC (if DST on, depending on date). We calculate that and store the UTC trigger time. This way, the notification system doesn’t need to deal with timezones – it just uses UTC.

In summary, timezone support means storing timezone metadata and always converting to/from UTC on input/output. It’s essential for a global user base to have correct times.

Additional Considerations

• Security & Permissions: We should note that calendars can be private or shared. In enterprise settings, you might allow viewing someone’s free/busy but not details. Our design could incorporate an access control check in the Event Service: e.g., only organizers or attendees can see event details, others might only see that you’re “busy.” This requires permission checks per event. We could extend the data model with a visibility setting or have separate “free/busy” lookup services that don’t reveal content.
• API Design: The system would expose RESTful or gRPC APIs like POST /events to create events, GET /users/{id}/events?range=thisweek to fetch events, PUT /events/{id} to update, POST /events/{id}/invitees/{userid}/rsvp to respond, etc. These should be designed to be idempotent where appropriate (especially creation – clients might retry a create call, and we should not duplicate the event if it was already processed; using an idempotency key or returning the existing event if a duplicate request arrives is important).
• Idempotency: To elaborate, for any operation (like creating an event) the client or gateway could attach a unique request ID. If the server sees the same ID again, it knows it’s a retry of the same operation and can avoid creating a duplicate. This is handled at the API gateway or application layer by storing recent request IDs (perhaps in a Redis with short TTL) or using database natural idempotency (like if the client can suggest an event ID, the second attempt will violate primary key and we detect it). Ensuring idempotent behavior makes the system robust to network retries and prevents double-booking from duplicate requests.

Example Schema (Simplified)

To tie it together, here is a simplified schema snippet showing some tables (for illustration):

Users Table (Users):

Calendars Table (Calendars):

Events Table (Events):

(Event 5001 is a weekly team meeting every Tuesday at 9am PDT by Alice, reserving Conf Room A. Event 5002 is a one-time call by Bob.)

Invitations Table (Invitations):

(Invitations: Event 5001 has Alice, Bob, Charlie; Alice’s own invite can be considered accepted automatically. Event 5002 has Bob and Alice.)

Rooms Table (Rooms):

(Rooms can optionally also have an associated calendar or be tied via events.room_id for bookings.)

This schema allows us to retrieve a user’s events by looking at events where their calendar_id = user’s calendar OR events where they appear in Invitations as invitee. We would likely create a view or a combined query to get “all events for user X” as those they organized (in their calendar) plus those they were invited to.

Now that we have covered data and core logic, we can turn to how we will scale and meet the performance targets.