This project involved building a comprehensive baggage management database system and user interface for the departure section of Bandaranaike International Airport (BIA) in Katunayake, Sri Lanka. The primary goal was to facilitate a real-time information flow covering both individual baggage tracking and the overall functionality of the baggage handling system to support operational use and live dashboard visibility.
I contributed to the system across the database, backend, and deployment layers. A significant portion of my work involved designing the PostgreSQL schema to handle the baggage workflow and developing a backend capable of processing high-velocity data. I was also responsible for deploying the entire system on an on-premise server environment isolated from external networks, ensuring the database layer remained responsive and reliable as baggage events moved through the departure pipeline.
Real-Time Baggage and Error Data Handling
As the country’s primary international hub, BIA handles a massive volume of baggage data. Efficiency and reliability were non-negotiable.
Messaging and Integration
The data was published to a RabbitMQ server queue configured with a redundant, two-server architecture. Building the consumer service in Java Spring Boot, I faced several key challenges:
- Redundancy: Implementing a round-robin mechanism to check the health of the servers and failover automatically if one was unavailable.
- Security: Managing SSL/TLS with self-signed certificates. This required careful handling of the certificate lifecycle within the application to ensure secure communication without compromising performance.
- Throughput: Tuning the RabbitMQ libraries and Spring Boot configurations to scale with high data volumes and process events effectively in real-time.
PLC and Database Logic
Beyond tracking bags, we needed real-time visibility into errors within the PLC (Programmable Logic Controller) systems. I designed a specialized external user role for the internal database, allowing external data to be written directly into specific staging tables. I then used PostgreSQL triggers to process this data in real-time. We specifically chose PostgreSQL for its robust support for these types of automated functions and its flexibility with various data types.
On-Premise Deployment Challenges
Due to airport security protocols, the system had to be deployed on an on-premise server isolated from internet and external networks. To ensure scalability and ease of updates, I opted for a Docker-based solution.
After researching local orchestration options, I chose KinD (Kubernetes in Docker). While KinD is traditionally a development tool, I found it to be a pragmatic choice for this specific Windows environment, offering more scalability and management features than standalone Docker containers. However, this path came with its own hurdles:
- Environment Constraints: Navigating the limitations of a Windows Server environment while being relatively new to Kubernetes at the time.
- Frontend Configuration: A major pain point was the Vite-based frontend. Since Vite injects environment variables at build time rather than run time, it reduced our flexibility during the deployment phase, requiring a more rigid build pipeline.
Technologies & Architecture Choices
Selecting the right stack was critical for meeting the airport’s strict requirements. Here is a breakdown of the technologies used, why they were chosen, and how I would optimize them in the future:
- Java & Spring Boot (Backend): It is an industry standard for enterprise applications, offering robust multithreading capabilities and excellent out-of-the-box integration for complex message queue processing.
- PostgreSQL (Database): We needed strict ACID compliance to ensure no baggage data was ever lost. Additionally, its powerful trigger functionality allowed me to bypass backend latency and process PLC errors instantly as they were written.
- Docker & KinD (Orchestration): Containerization was the best way to handle scalable deployments on Windows. KinD gave us access to Kubernetes features like self-healing and rolling updates locally with less complexity.
- Vite (Frontend): The easiest option to build a dynamic dashboard with easy configurations. In the starting phase we completely missed on the env variable challenge otherwise it is a good choice in terms of development effort and final output.
Conclusion
Deploying a high-availability, real-time system into an on-premise, secure airport environment was a massive undertaking. Despite the heavy lifting required to configure network redundancies, manage SSL certificates securely, and adapt Linux-first containerization tools to a Windows Server environment, the effort paid off.
This project pushed me to think deeply about system architecture from how messages are routed and consumed in RabbitMQ, to how database triggers can be leveraged for instant processing, all the way to the nuances of container orchestration. Today, the system successfully bridges the gap between physical baggage handling hardware and live operational dashboards, running reliably to support the daily departure operations of Bandaranaike International Airport.