A seasonal backend refers to a backend system or service that is only needed or heavily used during specific times or seasons. For example, an application might require extra backend resources during holiday sales, tax season, or sporting events, but not during the rest of the year. These backends can be scaled up or activated for peak periods and scaled down or deactivated when demand drops, optimizing costs and resources.
I couldn’t find the correct term for the above-mentioned type of a service, and decided to go with seasonal backend. Let me know if there is a better term for this.
I wanted to write about this because of my experience working on Mora Exams in 2025.
# What’s special?
Usually, a backend is deployed with a long-time deployment strategy. And the backend will be considered as the single source of truth. Changes to the database schema must be done carefully and thoroughly.
But in the case of seasonal backends, the backend is deployed only for a short period of time. The website is up all the time. Thus the website cannot be dependent on the backend. Outside the exams season, database schema changes can be done without any downtime, as the system is not in use.
A seasonal backend will be taken down after the season and redeployed for the next. The system must be easily deployable.
# What are Mora Exams?
Mora Exams is Sri Lanka’s one of the biggest pilot examinations for G.C.E. Advanced Level, an initiative by the students of University of Moratuwa, Faculty of Engineering. The exams are conducted each year for more than 8000 students. For Mora Exams 2025, I am serving as the Tech Coordinator.
# The Challenges
Despite being held for more than a decade, Mora Exams’ software infrastructure was very weak.
It was a PHP-based system initially. No source control was used. The code was directly copied from the developer’s machine to the server. Because of this, the code was kept untouched.
All core functionalities were done manually, outside the system and imported into the system. For example, student registrations was taken through Google Forms, results were calculated in Excel and then imported into the system’s database.
The database wasn’t designed like an engineer would. There were no documentation. And I can go on forever. In one word: the system wasn’t engineered.
In 2023 and 2024, the system undergone major changes. The system was rewritten in Golang, the database was redesigned, and a new admin dashboard was developed. A lot of issues were resolved with these changes. We are working on fixing the remaining issues in 2025. We are also working on improving the system’s infrastructure.
In this piece of writing, I want to share what I learnt about the infrastructure design of a seasonal backend.
# Lessons
# Development Setup
I have never felt containerization is important. I always thought they were an overkill, and expensive in terms of time and resources. However, I have learned that containerization is unavoidable when it comes to collaborative projects, which span across multiple years.
As I wanted to make sure everyone could contribute to the system easily, I have integrated docker compose into the backend to facilitate quicker development and deployment. Configuring docker compose was a bit tricky, even with the help of LLMs. It’s now fully setup and usable.
Now, new contributors can easily get started with the system without worrying about the local infrastructure setup. They can focus on the code and features they want to implement.
# Lack of Documentation
As I already mentioned above, there were no documentations for the system until now. In 2025, we started documenting the system and the design decisions. We are hoping to complete the documentation by the end of this year.
# Missing Features
The system is used by various kinds of users including organizing committee, coordinators, and students. Each type of users has different requirements and permissions. But the system was not designed with all kinds of requirements in mind. Important features for specific type of users were missing and only found missing while the exams are going on.
After the exams are over, we will conduct a small survey with the users and address the missing features.
# Testing
We were testing the system manually as we developed new features and fixed existing bugs. Obviously, this is not a sustainable approach. And it is very error-prone. We are planning on adding tests and automating the testing process.
# Auto Deployments
The backend is deployed manually by SSHing into the server. There are plans on implementing automated deployments. However, it’s not high priority, as the system is only up for a few months.
# Takeaway
I don’t know really. I learned a lot about the importance of design decisions, documentation, testing while working on Mora Exams 2025. LLMs can help us write code; but they cannot help us design a system, which is the most important step.