What data does Cronofy store?
In order to provide the sync and scheduling infrastructure to our software clients, we maintain a cache of the calendar data for users who have authorized access. This cached data is protect through encryption in transit and at rest. Our primary infrastructure provider, Amazon Web Services, provide the controls and management tools to secure this.
This main reasons we do this are:
1. Calendar Server Availability #
The ideal API access pattern for applications often conflict with desired API access patterns for a calendar server. Calendar servers are core infrastructure for any organization and thus ensuring they are available is critical.
By operating a cache and updating that cache in a way optimized for the calendar server, we can allow applications to interrogate that cache using patterns that would potentially disrupt operations for the calendar server.
2. Permissions #
The permissions model provided by calendar services is rudimentary. As part of our sync cache, we’re able to provide richer controls over the events in user’s calendars. For example, Cronofy is able to provide a permission called
FreeBusyWrite which isn’t possible with standard calendar permissions.
In this model the application can request only free-busy permissions on existing events in a user’s calendar yet still write its own events to the user’s calendar. Ideal for online booking situations where the actual content of a user’s calendar is irrelevant to the use case.
3. Reliability #
This allows us to track changes in calendars to deliver timely notifications to applications in a way that copes with any service issues on the calendar server side. Change notifications are not 100% reliable so we apply a variety of strategies to tracking changes. By driving change notifications from our cache we can be sure that however the update was recognized, it will be updated to our application customers in a timely fashion.
4. Speed #
By operating our scheduling calculations on a cache of the data, we’re able to deliver results incredibly quickly. If we had to query the calendar services for multiple users each time a lookup was performed this would in many cases make the service unusable.