Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

1. Users can schedule/reschedule/cancel a meeting with an agenda and notes at a room for a number of participants.

a. Support reccuring meetings?

1. Users are notified of meetings and can view agenda/notes accept or decline
2. Users can see the availability of rooms and persons
3. Integration with calendars.
4. Meeting reminders
5. History of meeting

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

1. Should support 1000 users.
2. Should support 20 meeting rooms.
3. Should allow booking for 5 meetings within 1 second and status is visible within 1 second
4. Should not allow double bookings
5. Security that only authorized roles can access
6. Audit logging

API Design

Define the APIs expected from the system...

1. GetAvailability:
   • Endpoint: GET /GetAvailability(DateStart, DateEnd)
   • Purpose: Returns a list of available rooms within the specified date range.
   • Response: List<Map<Room, List<KVP<Start, End>>> indicates which rooms are available, along with time slots.
2. CreateMeeting:
   • Endpoint: POST /CreateMeeting
   • Purpose: Schedule a new meeting with provided parameters such as room, participants, start and end times.
   • Consider defining the request body more clearly:
   • Body: { "room": "RoomID", "participants": ["UserID1", "UserID2"], "start": "DateTime", "end": "DateTime", "agenda": "string", "recurring": "boolean" }
3. UpdateMeeting:
   • Endpoint: PUT /UpdateMeeting(MeetingId)
   • Purpose: Update the details of an existing meeting by its ID.
   • Similar to CreateMeeting, consider specifying the request body format to clarify what can be updated.
4. CancelMeeting:
   • Endpoint: DELETE /CancelMeeting(meetingID)
   • Purpose: Cancel a scheduled meeting using its ID.
5. GetMeetingDetails:
   • Endpoint: GET /GetMeetingDetails(MeetingId)
   • Purpose: Retrieve all information about a specific meeting.
6. ExportCalendar:
   • Endpoint: GET /ExportCalendar
   • Purpose: Could be used to export scheduled meetings into various formats (e.g., CSV, iCal).
7. NotifyUsers:
   • Endpoint: POST /NotifyUsers
   • Purpose: Send notifications to users about meeting details (could include invites, reminders, etc.).
   • Suggest modifying the body to clarify the expected format:
   • Body: { "listOfUsers": ["UserID1", "UserID2"], "meetingDetails": { "meetingId": "string", "room": "RoomID", "agenda": "string", "start": "DateTime", "end": "DateTime" } }

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram. If unfamiliar with the tool, describe your design to the AI and ask it to generate a starter diagram...

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, and any relevant algorithms or data structures. Consider drawing detailed diagrams to enhance your explanation...

1. Api Layer
   1. We can front the API with an api gateway (such as aws) to implement ratelimiting. Or implement a simple ratelmiting.
   2. We can use versioning to manage future changes.
   3. Standardize with RESTful Nouns and verbs, return appropriate status codes.
   4. We can containerize and deploy to multiple instances to improve reliability and also geographical redundancy.
2. Schema:
   1. Users: id, name, email, role
   2. Meeting: id, roomid, start, end, agenda, recurrenceID (null)
   3. Room : capacity, id, name
   4. RoomReservations: id, room, meetingid

All ids and fks are indexed.

1. Notification Service:
   1. sqs, kafka, rabbitmk to insert notifications, listerners will send out notifications
   2. use websockets or server sent events to communicate to clients.
2. Logging and Monitoring : ELK or Cloudwatch or prometheus and grafana. Metrics listeners dropwizard or opentelemetry for instrumentation.