The calendar was the very reason I started building Algebra in the first place, and for a long time it seemed like the simplest part of the project. A student picks a slot, leaves their details and gets a confirmation, and I see the booking in the panel. For several weeks around the turn of the year, though, this simple mechanism was my biggest problem, because bookings simply vanished.
It is the most important lesson of the whole project, so I describe it in detail, including the paths that turned out to be dead ends.
What the calendar had to do
From the start I wanted individual and group lessons in one calendar, and that meant more than a plain list of free hours. Each lesson has its own length, groups have a limited number of places, and I need to be able to block a slot, enter a holiday and move a lesson. On top of that came a contact form, messages in the panel and emails: a booking confirmation for the student, a notification for me, and later a reminder with a link to the lesson.
At first I sent emails from an ordinary Gmail inbox, which the application used the same way an email program does. On a small scale that was enough, and in February I also added notifications to my phone and to WhatsApp, so a new booking would not have to wait until I checked my email.
The symptoms
In November strange things began to happen. After I uploaded a new version to the server (programmers call this a deployment), the site could show an error because the table with bookings or with messages had suddenly vanished from the database. Slot blocks set in the panel disappeared, and the bookings went with them, even though nobody had cancelled them.
I looked for the bug where it seemed logical to look, in the code. I added a safeguard so that a missing table would not bring the whole site down, a separate page for peeking at what was going on inside, and rebuilding of missing tables every time the application started. At the end of November I also had it keep detailed notes on what happened while the blocks were being saved, because I suspected that the save was failing somewhere along the way. Each of these fixes eased the symptoms, but none of them removed the cause.
The cause: a disk that does not remember
Algebra ran on the free plan of Render, the company that hosted my server, and the whole database was a single file on the same disk as the application. What I did not know back then cannot be read from the code, because it depends on the server: every time a new version is uploaded, Render builds the application from scratch, on a clean disk. Everything the application had saved locally since the previous time is lost.
That explained everything at once. I uploaded new versions often, sometimes several times a day, so the database went back just as often to the state in which it sat alongside the code. It was not only bookings that vanished, but everything the application kept in files on the server: settings, holidays and messages. The code did exactly what it was supposed to do. It just saved the data in a place that is temporary by design.
Three attempts at a database
First I tried to tidy up what I had and moved messages and settings from separate files into the database, so that everything would sit in one place. The problem remained, because that one place was still on the disappearing disk.
In January I turned to an unusual solution: I moved the database to Google Sheets. The application read and wrote data in a spreadsheet, so at last the data sat off the server, and I could view it, fix it or export it like in any spreadsheet. It worked, but slowly, because every time the application reached for data it had to go over the internet to the spreadsheet. So I soon added on-demand refreshing, so that the admin panel would not grind away with every click.
At the end of January I finally switched to a real database (PostgreSQL) on Neon, a company that keeps it on a separate server. A database like that knows nothing about how many times I upload a new version of the application, so from then on a new version changes only the code and the data stays where it was. The move still meant filling in missing fields, fixing the security of the forms and cleaning up old data, but the bookings stopped disappearing.
What follows from this
The most important conclusion sounds trivial, but it cost me several weeks: a database cannot live on the same disk as the application if that disk is temporary. With any application that saves anything, it is worth asking first where the data physically sits and what will happen to it when the next version is uploaded. The second conclusion is less obvious: when the symptoms are strange and cannot be reproduced on demand, it is worth looking for the cause outside the code, in how and where the application is run.
The third is about people rather than technology. A lost booking can mean a student who turns up for a lesson I know nothing about, or a slot sold twice. With a calendar that other people use, an error in saving data is not a minor glitch but someone's wasted afternoon.
The whole series
This is the second part of a series about how Algebra i Spółka came to be:
- The first Algebra: Flask, templates and the PHP I quickly gave up on
- Bookings that disappeared with every deployment
- Algebra from scratch: from Flask templates to React and TypeScript
- A price list in a file, Premium and my first payment gateway
- Tasks, a formula sheet and drawings that would not add up
I describe what the whole thing looks like today in the post Algebra i Spółka from the inside.