Design A Collaborative Meeting Scheduler - System Design

System requirements

Functional Requirements

User Registration and Login:
- Users should be able to create an account and log in using various methods (e.g., email, OAuth).
Calendar Integration:
- The system should integrate with Google Calendar, Outlook, and other calendar applications to read and write event data.
Meeting Scheduling:
- Allow users to create, modify, and delete meetings. Provide an interface to view attendees’ availability based on integrated calendars.
Time Zone Management:
- Automatically convert times based on participant time zones, and suggest optimal meeting times.
Notifications:
- Send email or push notifications for meeting updates, cancellations, and reminders.
Conflict Detection:
- Detect scheduling conflicts and suggest alternative time slots based on attendees’ availability.
Meeting Invites:
- Allow users to invite others via email or link sharing, with options to accept or decline the invitation.
Group Scheduling:
- Support scheduling for groups by checking multiple participants’ calendars simultaneously.

Non-Functional Requirements

Scalability:
- The system should be able to handle increasing numbers of users and concurrent scheduling requests.
High Availability:
- Ensure a 99.9% uptime SLA with robust failover strategies.
Performance:
- Response time for read operations (e.g., viewing calendar) should be under 200ms, and write operations should be under 500ms.
Security:
- Implement OAuth 2.0 for calendar access and enforce secure storage of user data.
Data Consistency:
- Ensure consistent synchronization between the system and external calendar applications.

Capacity estimation

User Base: Assume an active user base of 100,000 monthly active users (MAUs), with peak concurrency of 5% (5,000 users).

Meeting Frequency: Each user schedules an average of 10 meetings per month.

API Requests: Each meeting interaction (create, update, delete, check availability) involves 5 API requests.

Notification Frequency: Each meeting generates 2-3 notifications on average (e.g., reminders, updates).

API design

Meeting Scheduling APIs

Create Meeting
Endpoint: POST /api/v1/meetings
Request:
{
"title": "Team Sync",
"description": "Weekly sync-up meeting",
"start_time": "2024-10-08T15:00:00Z",
"end_time": "2024-10-08T16:00:00Z",
"organizer_id": "123456",
"attendees": [
"[email protected]",
"[email protected]"
]
}
Response:
{
"meeting_id": "987654",
"status": "Scheduled"
}

Modify Meeting

Endpoint: PUT /api/v1/meetings/{meeting_id}
Request:
{
"title": "Updated Team Sync",
"start_time": "2024-10-08T15:30:00Z",
"end_time": "2024-10-08T16:30:00Z"
}
Response:
{
"meeting_id": "987654",
"status": "Updated"
}

Availability and Conflict Checking APIs

Check Attendees' Availability
Endpoint: POST /api/v1/meetings/availability
Request:
{
"organizer_id": "123456",
"attendees": [
"[email protected]",
"[email protected]"
],
"date_range": {
"start": "2024-10-08T00:00:00Z",
"end": "2024-10-08T23:59:59Z"
}
}
Response:
{
"availability": [
{
"user": "[email protected]",
"slots": [
{
"start_time": "2024-10-08T09:00:00Z",
"end_time": "2024-10-08T11:00:00Z"
},
{
"start_time": "2024-10-08T14:00:00Z",
"end_time": "2024-10-08T16:00:00Z"
}
]
}
]
}

Notification APIs

Send Notification
Endpoint: POST /api/v1/notifications/send
Request:
{
"user_id": "123456",
"message": "Your meeting is scheduled for 2024-10-08 at 3:00 PM",
"type": "email"
}
Response:
{
"status": "Notification sent successfully"
}

Database design

High-level design

Key Components:

API Gateway: Handles incoming API requests, routing them to appropriate services, and manages authentication/authorization.
User Service: Manages user data, including registration, login, and profile information.
Meeting Scheduler Service: Handles meeting creation, updates, availability checks, and conflict resolution.
Notification Service: Manages sending notifications (email or push) for meeting updates, reminders, and invites.
Calendar Integration Service: Syncs data with external calendars (Google, Outlook) and ensures two-way synchronization.
Database: Stores user data, meeting information, and notification logs.

Request flows

Request Flow for Creating a Meeting

User sends a Create Meeting request via the API Gateway, providing meeting details like title, description, start and end time, and attendees.
The API Gateway routes this request to the Meeting Scheduler Service.
The Meeting Scheduler Service checks attendee availability by communicating with the Calendar Integration Service.
The Calendar Integration Service queries external calendars (e.g., Google Calendar) for each attendee.
If no conflicts are found, the Meeting Scheduler Service creates the meeting record in the Meeting Database and sends a response back to the API Gateway.
The Meeting Scheduler Service triggers the Notification Service to send invites to the attendees.
Attendees receive notifications and can accept or decline the invite, updating their status in the Meeting Database.

Detailed component design

Meeting Scheduler Service

Handles meeting creation, updates, and deletion.
Checks for conflicts in scheduling and proposes optimal time slots based on attendees' availability.
Manages the state of meetings (e.g., pending, confirmed, or canceled).

Calendar Integration Service

Syncs meeting data between the internal scheduler and external calendar applications (e.g., Google Calendar, Microsoft Outlook).
Performs real-time availability checks for users.

Notification Service

Sends meeting-related notifications (e.g., new invite, updates, cancellations) to users via email or push notifications.
Keeps track of notification status and retries failed notifications.

Trade offs/Tech choices

Database Selection

Choice: PostgreSQL for structured meeting data and Redis for caching availability results.
Reason: PostgreSQL supports ACID transactions, ensuring data integrity, while Redis enhances read performance.
Trade-off: Increased cost and complexity due to managing multiple databases.

Third-Party Calendar Integration

Choice: Google Calendar and Microsoft Outlook APIs.
Reason: Widely adopted standards for business and personal scheduling.
Trade-off: Dependence on third-party APIs for data availability and rate limits that may hinder scalability.

Failure scenarios/bottlenecks

Calendar Integration Rate Limits

Scenario: Exceeding API call limits for third-party calendar services.
Mitigation: Implement request throttling and use caching (Redis) to store previously fetched calendar data, reducing repeated requests.

2. Meeting Scheduler Service Overload

Scenario: High volume of scheduling requests causing slow response times.
Mitigation: Use a distributed queue (e.g., Kafka) to handle requests asynchronously, and implement auto-scaling based on the workload.

3. Notification Service Downtime

Scenario: Notification service goes down, causing missed updates or reminders.
Mitigation: Implement a retry mechanism with exponential backoff and use an external logging service to track failures.

4. Data Consistency Issues

Scenario: Conflicts in meeting data when syncing with external calendars.
Mitigation: Use distributed transactions where necessary and maintain an audit log to track changes.

Future improvements

Advanced Analytics: Add analytics dashboards for users to see metrics such as meeting frequency, duration, and attendance patterns.

Support for Additional Calendar Providers: Expand integrations to include more calendar services, such as Apple Calendar, to cater to a broader audience.

Enhanced Security Features: Implement multi-factor authentication (MFA) and data encryption to further enhance system security and protect sensitive user information.