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": [
    "user1@example.com",
    "user2@example.com"
  ]
}

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": [
    "user1@example.com",
    "user2@example.com"
  ],
  "date_range": {
    "start": "2024-10-08T00:00:00Z",
    "end": "2024-10-08T23:59:59Z"
  }
}

Response:
{
  "availability": [
    {
      "user": "user1@example.com",
      "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

erDiagram
    USER {
        UUID user_id PK
        string email
        string password_hash
        string name
        string time_zone
        datetime created_at
        datetime updated_at
    }
    
    MEETING {
        UUID meeting_id PK
        string title
        text description
        datetime start_time
        datetime end_time
        UUID organizer_id FK
        datetime created_at
        datetime updated_at
    }
    
    ATTENDEE {
        UUID attendee_id PK
        UUID meeting_id FK
        UUID user_id FK
        enum status
        datetime response_time
    }
    
    NOTIFICATION {
        UUID notification_id PK
        UUID user_id FK
        string message
        enum type
        enum status
        datetime created_at
    }

    USER ||--o{ MEETING : "organizes"
    USER ||--o{ ATTENDEE : "attends"
    MEETING ||--o{ ATTENDEE : "includes"
    USER ||--o{ NOTIFICATION : "receives"

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.

graph TD
    A[API Gateway] --> B[User Service]
    A --> C[Meeting Scheduler Service]
    A --> D[Notification Service]
    A --> E[Calendar Integration Service]
    B --> F[(User Database)]
    C --> F
    C --> G[(Meeting Database)]
    D --> H[(Notification Database)]
    E --> I[(External Calendars)]

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.

sequenceDiagram
    participant User
    participant API Gateway
    participant Meeting Scheduler Service
    participant Calendar Integration Service
    participant Notification Service
    participant Meeting Database
    participant External Calendars
    
    User->>API Gateway: POST /meetings
    API Gateway->>Meeting Scheduler Service: Create Meeting
    Meeting Scheduler Service->>Calendar Integration Service: Check Attendee Availability
    Calendar Integration Service->>External Calendars: Query Availability
    External Calendars-->>Calendar Integration Service: Return Availability
    Calendar Integration Service-->>Meeting Scheduler Service: Availability Data
    Meeting Scheduler Service->>Meeting Database: Store Meeting Details
    Meeting Scheduler Service-->>API Gateway: Meeting Created
    API Gateway-->>User: Meeting ID and Details
    Meeting Scheduler Service->>Notification Service: Send Meeting Invites
    Notification Service->>User: Notifications Sent

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.

Solutions

nectar4678 - 10/07/2024

0