Overview
The system should allow users (tutors in this case) to add their own availability time slots. For example, a tutor says that s/he is available this specific week on Thursday from 5.30pm to 6.30pm, then from 8pm to 9pm. For simplicity, the duration of the availability == the duration of the session that may or may not be booked by a tutee.
Each tutor is assigned to specific courses and the tutor’s availability should show for all the classes s/he is assigned to.
Tutors also have access to their calendars where they see all the availability they have added for a specific week, and can either delete or modify some, and of course add new ones.
The application is small to medium.
Scenario
When a tutee navigates to a course page, s/he looks at all available tutors and their corresponding time slots, chooses the suitable timeslot, provides some details about the session (specific chapter, etc.), then submit his/her request. On server-side, a session is created according to the timeslot, and the timeslot is flagged as booked.
Models
I am using MongoDB + mongoose. This is what I have so far:
const course = new mongoose.Schema({
tutors: ({ type: mongoose.Schema.Types.ObjectId, ref: 'User' }),
title: String,
description: String,
})
const availability = new mongoose.Schema({
user: { type: mongoose.Schema.Types.ObjectId, ref: 'User' },
booked: Boolean,
startTime: Date,
endTime: Date
})
There are some corner cases that made me wonder whether I’m on the right track or not. For example, if a tutee books a session based on a specific availability, that availability is flagged as booked. All it takes for the tutor to appear available again is for him/her to delete the availability, then add a new one again at the same time. We would end up with 2 sessions taking place at the same time, which is not accepted. Of course I can add a unique index on the start and end times, but overlapping sessions/availability are also a problem.
What do you think about this design? Do you see any potential limitations/problems with this design? Is there anything you would do differently? Do those corner cases stem from a bad design, or there isn’t much that can be done for that other than application level checking?
I tried looking for similar problems but couldn’t really make strong correlations between my case and the generic hotel/room/booking reservation systems.
Thank you.