Slots of doctors used to be constructed on request previously, then a caching layer was added, ie slots used to be constructed and then stored in redis, on next request, slots stored used to be fetched from cache and returned to user, reducing the construction load on the microservice. This architecture had its issue as slots were not stored in a proper data structure, but as a stringified json due to their complex nature. A new requirement to show doctor's next available slot was upon us and we knew fetching from cache and finding next available slot would again cause high computation.
Hence I came up with the architecture of storing doctor's slots in MongoDB. Slots would be calculated through a cronjob at night during low traffic and stored as dates divided into slots as per doctor's set appointment duration. This made our requirement to show next available slot a simple database query and allowed us to pack in new features such as allowing multiple appointments for a single slot! Marking a slot active/inactive in case of cancellation/booking is easily handled through Kafka Events from the doctor's practice management microservice