Creating a serverless scheduling service in Golang

I’ve had a nice amount of exposure to the Golang language when I first started playing around with docker and its environment. At one time I actually had to go through the docker source code and the accompanying kernel source code for namespaces, cgroups and some other stuff. I had done some simple code execution and modifications but not a large scale system design.

I wanted to design a serverless system to emulate the calendaly service functionality. I’m all for paying for services, but not something that I could whip up myself quickly. I am still in the middle of my post how I eliminated Wordpress and managed to avoid paying for siteleaf. I usually use these use cases as oppurtunities to play around with something new and different, as opposed to just using some tool I could pay for…what fun is there in that?

I have a nice amount of meetings with people from consulting to networking and like the idea of having a simple url to easily allow a perspective meeting to be booked without exposing my calendar. Since this was more of an experiment with Golang and to see if I can pull this off as a serverless model with minimal fuss I had a fairly generic set of requirements. My initial requirements were:

1. Have a url where anonymous users may requests a meeting with me of several pre-defined durations (event types).
2. The system should be able to at a minimum find available time slots for the requests events.
3. Assuming the user found an appointment slot the system should be able to insert the event into my calendar as well as send the user a calendar invite.

I had another challenge for myself and that was to see if I could do this without needing any additional storage mechanisms beyond the Google calendar.

I decided to extend this initial MVP and start with a schedule model first. The idea of this schedule model would be able to define general boundaries that guide your daily and weekly calendar. I came up with this approach:

1. Define a set of days that are either enabled or disabled. A disabled day is not even taken into consideration for any scheduling
2. Define time spans for single, multiple, or all days of the week that should be considered as busy.

I realized that the state of Availability can be one of three:

1. Busy - A known event
2. Available- A known free slot
3. Unknown- There is no rule which indicates that the time is busy or free

You may ask yourself…what’s with the unknown…if you don’t have anything on the calendar don’t you just assume you are free? The answer is that it depends on what type of calendar this is.