System requirements

Functional:

Highest:

1. Meeting Creation: Users should be able to schedule new meetings, specifying details like date, time, duration, participants, and agenda.
2. Meeting Management: Users can edit or delete existing meetings, as well as manage participant lists.
3. Recurring Meetings: Support for scheduling recurring meetings on a daily, weekly, or monthly basis.

Medium:

1. Notifications and Reminders: A system to send notifications to participants about upcoming meetings, changes, or cancellations.
2. Search and Filter: Users can search for meetings and filter them based on various criteria like dates, participants, etc.
3. Availability Checking: Users can check the availability of participants before scheduling a meeting to avoid conflicts.

Lowest:

1. User Roles and Permissions: Different access levels for users (e.g., admin, regular user) to manage meetings effectively.
2. Integration with Calendars: Sync with external calendar systems (like Google Calendar, Outlook) to keep all events consolidated.

Non-Functional:

List non-functional requirements for the system...

Capacity estimation

Estimate the scale of the system you are going to design...

API design

Here's a structured API design for the meeting scheduling system, covering the core functionalities.

1. Meeting Creation API

Endpoint: POST /api/meetings

• Description: Creates a new meeting with specified details.
• Request Body:

• Response:
  • 201 Created: Meeting created successfully.
  • 400 Bad Request: Validation errors, such as missing fields or invalid date/time.
• Sample Response:

2. Meeting Management APIs

Endpoint: GET /api/meetings/{meeting_id}

• Description: Fetches details of a specific meeting.
• Response:
  • 200 OK: Meeting details returned.
  • 404 Not Found: Meeting not found.
• Sample Response:

Endpoint: PUT /api/meetings/{meeting_id}

• Description: Updates the details of an existing meeting.
• Request Body (only fields to update are required):

• Response:
  • 200 OK: Meeting updated successfully.
  • 404 Not Found: Meeting not found.
  • 400 Bad Request: Validation errors, such as invalid date/time.
• Sample Response:

Endpoint: DELETE /api/meetings/{meeting_id}

Description: Deletes an existing meeting.

• Response:
  • 200 OK: Meeting deleted successfully.
  • 404 Not Found: Meeting not found.
• Sample Response:

3. Recurring Meetings API

Endpoint: POST /api/recurring-meetings

Description: Creates a recurring meeting series.

• Request Body:

• Response:
  • 201 Created: Recurring meeting series created.
  • 400 Bad Request: Validation errors.
• Sample Response:

4. Notifications and Reminders API

Endpoint: POST /api/notifications

Description: Schedules notifications for a specific meeting.

• Request Body:

• Response:
  • 200 OK: Notifications scheduled successfully.
  • 404 Not Found: Meeting not found.
  • 400 Bad Request: Validation errors.
• Sample Response:

5. Search and Filter API

Endpoint: GET /api/meetings

Description: Searches and filters meetings based on criteria.

• Query Parameters:
  • date: Date of the meeting (e.g., 2024-11-10).
  • participant: Participant ID to filter meetings by participant.
  • keyword: Keyword in the title or agenda.
• Example Request: /api/meetings?date=2024-11-10&participant=user_id1
• Response:
  • 200 OK: List of matching meetings.
  • 400 Bad Request: Invalid query parameters.
• Sample Response:

6. Availability Checking API

Endpoint: POST /api/availability

Description: Checks availability of participants for a new meeting.

• Request Body:

• Response:
  • 200 OK: Returns availability status.
  • 400 Bad Request: Validation errors.
• Sample Response:

Database design

Database Schema

1. Users Table

Stores information about users (meeting participants).

• Primary Key: user_id

2. Meetings Table

Stores details of individual meetings.

• Primary Key: meeting_id
• Foreign Key: created_by references Users(user_id)

3. Participants Table

Stores participant information for each meeting, allowing a many-to-many relationship between meetings and users.

• Primary Key: (meeting_id, user_id)
• Foreign Key: meeting_id references Meetings(meeting_id)
• Foreign Key: user_id references Users(user_id)

4. Recurring Meetings Table

Stores details for recurring meetings.

• Primary Key: recurring_id
• Foreign Key: meeting_id references Meetings(meeting_id)

5. Notifications Table

Stores information on scheduled notifications for meetings.

• Primary Key: notification_id
• Foreign Key: meeting_id references Meetings(meeting_id)
• Foreign Key: user_id references Users(user_id)

6. Availability Table

Stores participant availability data to check for scheduling conflicts.

• Primary Key: (user_id, busy_start, busy_end)
• Foreign Key: user_id references Users(user_id)

Relationships and Indexing Suggestions

1. Relationships:
   • Users to Meetings: One-to-many via created_by.
   • Meetings to Participants: Many-to-many via Participants table.
   • Meetings to Notifications: One-to-many, as each meeting can have multiple notifications.
2. Indexes:
   • Index date and time in Meetings for fast retrieval based on meeting time.
   • Index user_id in Participants to quickly find all meetings a participant is involved in.
   • Index send_at in Notifications to efficiently retrieve upcoming notifications.
   • Composite index on user_id, busy_start, busy_end in Availability to optimize availability checking.

High-level design

User Interface (UI)

• Description: Provides a web or mobile interface for users to interact with the system. The UI allows users to schedule meetings, view notifications, manage participants, and configure recurring events.
• Technology: Web (React, Angular, or Vue) and Mobile (iOS, Android with Flutter or React Native).

API Gateway

• Description: Acts as an entry point for all client requests, routing them to the appropriate backend services.
• Functionality: Handles authentication, rate limiting, and routing. It ensures secure and authorized access to backend services.
• Technology: NGINX, Kong, or AWS API Gateway.

Backend Services (Microservices)

• Description: A set of independent, modular services to handle the core functionalities of the system, such as meeting management, notifications, user management, and availability checking.
• Technology: RESTful APIs or GraphQL, implemented with Java/Spring Boot, Node.js/Express, or Python/FastAPI.

Request flows

Meeting Creation Workflow

• User submits a meeting creation request via the UI.
• API Gateway forwards the request to the Meeting Management Service.
• The Meeting Management Service creates the meeting record, checks for conflicts (Availability Service), and generates notifications (Notification Service).
• If the meeting is recurring, the Meeting Management Service saves recurrence rules and schedules the next occurrences.

Notification Workflow

• Notification Service listens for meeting creation or updates through the Messaging Queue.
• It schedules reminders based on user preferences and meeting start time.
• At the designated time, the Notification Service sends reminders through the appropriate channel (email or SMS).

Recurring Meetings Workflow

• Scheduler/Task Runner triggers recurring meeting setup at scheduled intervals.
• Meeting Management Service generates new instances based on recurrence rules.
• Notification Service is informed of these instances to set reminders.

Availability Checking Workflow

• When creating or updating a meeting, Meeting Management Service calls Availability Service to verify participants’ availability.
• Availability Service checks the user’s internal meeting schedule and external calendar availability.
• It returns any conflicts or suggests alternate meeting times.

Search and Filter Workflow

• User searches for meetings by date, participant, or keyword through the UI.
• API Gateway forwards the request to the Search & Filter Service, which queries the database or cache for relevant meetings.
• Results are returned and displayed in the user’s interface.

Detailed component design

Meeting Management Service

Functionality:

• Meeting Creation and Editing: Handles requests to create or modify meetings, setting details like date, time, duration, participants, and agenda.
• Recurring Meetings: Stores recurrence rules and generates future occurrences based on user-specified intervals (daily, weekly, monthly).

Detailed Design:

• Data Storage: Relational database (e.g., PostgreSQL) for structured meeting data, ensuring data integrity and supporting complex queries.
• API Endpoints:
  • POST /meetings: Create a new meeting, validate details, and save.
  • PUT /meetings/{id}: Update meeting details.
  • DELETE /meetings/{id}: Delete a meeting and associated data like notifications.
• Recurring Meeting Processing:
  • Option 1: Store recurrence rules and create only the first instance in the database. A scheduler creates future instances when the date approaches.
  • Option 2: Pre-generate instances for a set period (e.g., a month) and add them to the database.

Tradeoffs:

• Option 1 (Generate instances on demand):
  • Pros: Saves storage and avoids having to store many future events, making updates to recurrence rules easier.
  • Cons: Requires a scheduler, which can add latency for retrieval and complexity in managing when to create new instances.
• Option 2 (Pre-generate instances):
  • Pros: Faster querying and predictable scheduling; users can see all occurrences in advance.
  • Cons: Higher storage usage, especially if many users schedule recurring meetings, and more complex updates if a rule changes.

2. Notification Service

Functionality:

• Notifications and Reminders: Send notifications before meetings and updates on changes or cancellations.
• Notification Channels: Supports email and SMS (extendable to push notifications).

Detailed Design:

• Queue-based Processing: A messaging queue (e.g., RabbitMQ or Apache Kafka) processes notification tasks asynchronously, decoupling the Notification Service from other services.
• Scheduler Integration: Uses a task scheduler (e.g., Celery, Quartz) to send notifications based on meeting start times and user preferences.
• API Endpoints:
  • POST /notifications: Schedule a notification for a meeting.
  • DELETE /notifications/{id}: Cancel scheduled notifications for canceled or rescheduled meetings.
• Database Schema:
  • notification_id, meeting_id, user_id, send_at, status.

Tradeoffs:

• Email vs. SMS vs. Push:
  • Email: Reliable, but can be delayed by email providers and may end up in spam.
  • SMS: Quicker but costlier per message; better suited for urgent reminders.
  • Push: Free and instant but requires an app.
• Immediate vs. Scheduled Notifications:
  • Immediate: Directly trigger a notification for important changes; uses resources quickly but provides instant feedback.
  • Scheduled: Queue notifications and rely on a scheduler, improving scalability but adding some delay.

3. User Service

Functionality:

• User Management: Handles user profile data, authentication, and role-based access control.
• Participant Management: Tracks RSVPs for each meeting and notifies users of meeting changes.

Detailed Design:

• Authentication:
  • Uses JWT tokens or OAuth2 for secure, scalable authentication.
  • External OAuth providers (e.g., Google or Microsoft) are optional, enabling calendar integration.
• User Data Storage:
  • Stores users with a user_id, name, email, phone, and roles in a relational database.
• Participant Management:
  • Each meeting can have multiple participants, with a relational link (join table) in a Participants table for efficient lookups.

Tradeoffs:

• OAuth Integration:
  • Pros: Easier access to third-party calendars, secure authentication.
  • Cons: More complex implementation and handling of third-party API rate limits.
• Relational vs. NoSQL Storage for User Data:
  • Relational: Easier to query relationships between meetings and participants.
  • NoSQL: Better for high read/write scalability but more complex joins for relational data.

4. Availability Service

Functionality:

• Availability Checking: Prevents scheduling conflicts by checking user availability.
• Integration with External Calendars: Syncs with Google Calendar, Outlook, etc., to get real-time availability.

Detailed Design:

• Internal Availability Check:
  • Query the database for user schedules and compare proposed meeting times.
  • Store availability blocks in a separate table with user_id, busy_start, and busy_end.
• External Calendar Sync:
  • Use APIs (e.g., Google Calendar API) to pull busy/free data for participants.
  • Data is either cached for performance or requested on-demand based on rate limits.
• API Endpoints:
  • GET /availability/check: Check availability for specified users within a time range.

Tradeoffs:

• On-Demand vs. Cached External Availability:
  • On-Demand: Real-time accuracy but more API calls and can hit rate limits.
  • Cached: Reduces API calls, but data can be slightly outdated and may need refresh logic.
• Availability Block Storage:
  • Database: Simplifies data management and retrieval for internal schedules.
  • In-Memory Store (e.g., Redis): Faster but requires synchronization with the database.

In a detailed design for a meeting scheduling system, we break down each core functionality, describe the technical components involved, and evaluate tradeoffs for scalability, maintainability, and complexity. Below, I’ll cover each core service, how it works, and some design choices with tradeoffs.

1. Meeting Management Service

Functionality:

• Meeting Creation and Editing: Handles requests to create or modify meetings, setting details like date, time, duration, participants, and agenda.
• Recurring Meetings: Stores recurrence rules and generates future occurrences based on user-specified intervals (daily, weekly, monthly).

Detailed Design:

• Data Storage: Relational database (e.g., PostgreSQL) for structured meeting data, ensuring data integrity and supporting complex queries.
• API Endpoints:
  • POST /meetings: Create a new meeting, validate details, and save.
  • PUT /meetings/{id}: Update meeting details.
  • DELETE /meetings/{id}: Delete a meeting and associated data like notifications.
• Recurring Meeting Processing:
  • Option 1: Store recurrence rules and create only the first instance in the database. A scheduler creates future instances when the date approaches.
  • Option 2: Pre-generate instances for a set period (e.g., a month) and add them to the database.

Tradeoffs:

• Option 1 (Generate instances on demand):
  • Pros: Saves storage and avoids having to store many future events, making updates to recurrence rules easier.
  • Cons: Requires a scheduler, which can add latency for retrieval and complexity in managing when to create new instances.
• Option 2 (Pre-generate instances):
  • Pros: Faster querying and predictable scheduling; users can see all occurrences in advance.
  • Cons: Higher storage usage, especially if many users schedule recurring meetings, and more complex updates if a rule changes.

2. Notification Service

Functionality:

• Notifications and Reminders: Send notifications before meetings and updates on changes or cancellations.
• Notification Channels: Supports email and SMS (extendable to push notifications).

Detailed Design:

• Queue-based Processing: A messaging queue (e.g., RabbitMQ or Apache Kafka) processes notification tasks asynchronously, decoupling the Notification Service from other services.
• Scheduler Integration: Uses a task scheduler (e.g., Celery, Quartz) to send notifications based on meeting start times and user preferences.
• API Endpoints:
  • POST /notifications: Schedule a notification for a meeting.
  • DELETE /notifications/{id}: Cancel scheduled notifications for canceled or rescheduled meetings.
• Database Schema:
  • notification_id, meeting_id, user_id, send_at, status.

Tradeoffs:

• Email vs. SMS vs. Push:
  • Email: Reliable, but can be delayed by email providers and may end up in spam.
  • SMS: Quicker but costlier per message; better suited for urgent reminders.
  • Push: Free and instant but requires an app.
• Immediate vs. Scheduled Notifications:
  • Immediate: Directly trigger a notification for important changes; uses resources quickly but provides instant feedback.
  • Scheduled: Queue notifications and rely on a scheduler, improving scalability but adding some delay.

3. User Service

Functionality:

• User Management: Handles user profile data, authentication, and role-based access control.
• Participant Management: Tracks RSVPs for each meeting and notifies users of meeting changes.

Detailed Design:

• Authentication:
  • Uses JWT tokens or OAuth2 for secure, scalable authentication.
  • External OAuth providers (e.g., Google or Microsoft) are optional, enabling calendar integration.
• User Data Storage:
  • Stores users with a user_id, name, email, phone, and roles in a relational database.
• Participant Management:
  • Each meeting can have multiple participants, with a relational link (join table) in a Participants table for efficient lookups.

Tradeoffs:

• OAuth Integration:
  • Pros: Easier access to third-party calendars, secure authentication.
  • Cons: More complex implementation and handling of third-party API rate limits.
• Relational vs. NoSQL Storage for User Data:
  • Relational: Easier to query relationships between meetings and participants.
  • NoSQL: Better for high read/write scalability but more complex joins for relational data.

4. Availability Service

Functionality:

• Availability Checking: Prevents scheduling conflicts by checking user availability.
• Integration with External Calendars: Syncs with Google Calendar, Outlook, etc., to get real-time availability.

Detailed Design:

• Internal Availability Check:
  • Query the database for user schedules and compare proposed meeting times.
  • Store availability blocks in a separate table with user_id, busy_start, and busy_end.
• External Calendar Sync:
  • Use APIs (e.g., Google Calendar API) to pull busy/free data for participants.
  • Data is either cached for performance or requested on-demand based on rate limits.
• API Endpoints:
  • GET /availability/check: Check availability for specified users within a time range.

Tradeoffs:

• On-Demand vs. Cached External Availability:
  • On-Demand: Real-time accuracy but more API calls and can hit rate limits.
  • Cached: Reduces API calls, but data can be slightly outdated and may need refresh logic.
• Availability Block Storage:
  • Database: Simplifies data management and retrieval for internal schedules.
  • In-Memory Store (e.g., Redis): Faster but requires synchronization with the database.

5. Search and Filter Service

Functionality:

• Search Meetings: Allows users to search meetings by title, date, or participants.
• Filters: Supports filtering by attributes like dates, keywords, and participant lists.

Detailed Design:

• Search Engine:
  • Option 1: Database search with SQL and indexing (simple, low-cost for small datasets).
  • Option 2: Use a dedicated search engine like Elasticsearch for faster, full-text search.
• Caching:
  • Caches popular search results or commonly filtered items to improve performance.
• API Endpoints:
  • GET /meetings/search: Search by title, participant, date, etc.

Tradeoffs:

• SQL Search vs. Elasticsearch:
  • SQL Search: Efficient for structured queries, simpler to manage; may slow down with large datasets.
  • Elasticsearch: Optimized for full-text search, ideal for larger datasets; adds infrastructure and complexity.

Trade offs/Tech choices

Data Storage Considerations

1. Relational Database (e.g., PostgreSQL/MySQL):
   • Use: Meeting details, user profiles, participant relationships.
   • Tradeoff: Consistent structure and easier to manage relationships, but potentially limited horizontal scalability for large datasets.
2. NoSQL Database (e.g., MongoDB/Redis):
   • Use: Storing availability cache, frequently accessed data.
   • Tradeoff: Provides horizontal scalability but is less suited for complex joins or relational data.
3. In-Memory Store (e.g., Redis):
   • Use: Caching search results, availability checks.
   • Tradeoff: Faster access for high-read operations but requires frequent synchronization with primary data storage.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?