Post 4 – Design for the COFB Digital Client Check-In & Appointment System
Lindsey Stead | COMP 4911 Capstone Project
This post summarizes the software architecture and design for the COFB Digital Client Check-In & Appointment System. The design follows an API-first, modular, n-tier architecture that integrates with Link2Feed as a data source, while keeping a CSV fallback path so the system remains usable for the organization in the absence of a paid Link2Feed API key. The design will align with the analysis report that included topics related to the problem domain, system assumptions & constraints, system requirements, use cases, domain model, workflows, and risks.
For the design phase of the COFB Digital Check-In and Appointment System, the goal is to shift from the requirements and analysis phases while setting the stage for the next phase, which is the direct implementation of the software system. The goal here was to take all the functional and non-functional requirements from the analysis phase and turn them into a high-level design that actually makes sense for both clients and admins. The design had to be simple to use on the client side, flexible on the admin side, and still keep scalability in mind. Since the project scope shifted, I built in an API-first approach using Link2Feed’s RESTful client, but I also kept a CSV fallback so the system keeps running even without an API key. That way, it still improves workflows for the food bank while dealing with the real-world constraints.
Design Goals
The design phase focuses on three key system priorities:
- API-First Approach with CSV Fallback – The backend system is swappable to align with the system resilience requirement. The system is being designed so that it first checks for a Link2Feed API access, and in the event that no API key is detected by the system, it seamlessly falls back to a daily CSV export without interrupting services to ensure that the system is scalable and usable by the organization. The system will be designed to ensure this requirement is met by following all Link2Feed Developer Documentation files that are available.
- Simple, Accessible Client Experience – Clients can check in via QR code or by entering their name/phone. From there, they can confirm dietary preferences, request help, and view their next scheduled appointment and confirm whether they want SMS or email reminders, which are dispatched immediately since there is no long-term data storage outside Link2Feed.
- Simplified Outputs and Features for Admins – The admin panel is a separate intuitive and modern interface that is being designed to consolidate the completed and future daily check-in appointments for the day, by displaying an analytics component which is updated in real time and displays the overall live daily client activity into a real-time dashboard view. The system also supports auto generated printable tickets that include the client’s next appointments, dietary and special preferences, and household details, all aligned with the project scope.
High-Level Architecture Software Design
The COFB system is being designed as an n-tier architecture, which is where each component remains modular and easy to extend and scale in the future:
- Presentation Tier – Clients access the web application through a mobile device, or a kiosk using a QR code, or while staff use the admin panel defined by a non public-facing separate route where they can view and monitor the day’s client check-ins based on Link2Feed API calls or through uploaded CSV files that are directly exported from Link2Feed, manage client’s special requests and dietary preferences, view assistance notification and print tickets to assist in food packing and preparation.
- Application Tier – The check-in app handles authentication for clients accessing the system (via name/phone), dietary and special preferences, and help requests. It posts this data to the admin panel in real time and allows for automatic printing of the appointment slips to give to clients.
- Data Tier – Appointments and preferences are pulled from the Link2Feed API when available. If the API is down or unavailable, the system falls back to parsing a daily CSV export in line with Link2Feed’s export schema.
- Integration Tier – Notifications are sent via SMS or email according to client preferences that they select during the check-in process, and tickets are printed automatically through print services features after each successful check-in.
The selection of an n-tier software architecture design was chosen because this design best supports clients and administrators always have real-time access to the day’s appointment data through two distinct experiences: a simple, intuitive interface for clients, and a streamlined admin dashboard for staff, regardless of whether the food bank is using the API or CSV workflows. It also provides a smooth bridge from present-day CSV-based operations toward future API-enabled workflows, while ensuring that the project remains in scope.
Design Trade-Offs and Considerations
- No Persistent Database or Long-term Data Storage – By design, the system does not store data long-term; instead, it acts as a real-time pass-through between client interactions and Link2Feed data sources via RESTful API calls. This design choice avoids duplicating services, meets organizational requirements and scope changes, and keeps the system lightweight, scalable, and aligned with timelines and constraints. To account for the possibility of network outages and ensure system availability during peak business hours, additional safeguards (such as temporary in-memory caching or retry logic) which may be implemented, time permitting.
- Fallback as a Core Feature – Instead of relying on CSV handling as a temporary patch, the system will be designed to treat the CSV parsing and reliance as a core fallback pathway in the absence of a Link2Feed API key. This guarantees that the system can maintain its operability in the event that API access is unavailable or provides system redundancy and dependability in the event that Link2Feed integration features encounter an error.
- Scalability via Modular Tiers – By separating presentation, application, data, and integration tiers, the system can scale easily. For example, replacing the CSV parser with a direct API connector requires no changes to the client or admin experience.
Looking Ahead: Implementation Phase
With the COFB software design phase complete, the next phase is implementation. The implementation phase will cover the technologies that have been selected for the front-end and back-end based on the requirements, analysis, and design phase details, as well as outline how the system handles API requests vs. CSV parsing, and how the integration tier which includes the notification reminders and ticket printing for hamper preparation is built and tested.