Post 4 – Design for the COFB Digital Client Check-In & Appointment System

lindsea89 Post 4: Design
August 19, 2025

Post 4 – Design for the COFB Digital Client Check-In & Appointment System

Lindsey Stead | COMP 4911 Capstone Project

This post goes over the design phase for the COFB Digital Client Check-In and Appointment System. The system was designed using an incremental and Agile development approach that follows a modular and n-tier software architectural design pattern that resembles a hybrid style set-up. The hybrid n-tier style setup for this system allows the COFB to use the system’s core functionalities right out-of-the-box, while also providing them with a robust backend structure that was designed using Link2Feed developer documentation which has all API endpoints set-up should the COFB have access to their database provider’s API key in the future. The design phase was challenging considering a mid-development scope change that required careful reconsiderations of products based on new information. The goal of this software was to maintain functionalitiesfo for the COFB that assist their increasing demands as an organization by providing them with two separate frontend components, with CSV importing and exporting features. The hybrid and separate modular layers in the design model became a secure and scalable design model for the system that allowed for a clear seperation of concerns between the layers of the system while also offering the COFB functionalities without access to an API-key.

Design Goals

The design phase focuses on three key system priorities:

  1.  CSV-First and API-Ready  – The backend system is designed to work out-of-the-box with CSV files that are exported directly out of the organization’s current database provider (Link2Feed). During development it was determined that the organization does not have acess to  the API key at this time, and thus the system will be designed to process CSV files that are manually exported directly from their Link2Feed dashboard and uploaded into the system. The system is designed to be future-proof and scalable in the event that an API-key is purchased. The backend system was designed using a series of developer documents for Link2Feeds RESTful API interactions and these presented scope changes for the project.
  2. Simple, Accessible, Responsive 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.
  3. 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.

High-Level Architecture Software Design

The COFB system is being designed as hybrid and n n-tier architecture, which is where each component remains modular and easy to extend and scale in the future:

  1. 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.
  2.  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.
  3. Data Tier – Appointments are first handled via daily CSV exports from Link2Feed. If the API key becomes available in the future, the system will be designed and implemented to connect directly to Link2Feed’s database for client information, appointment management by connecting directly to Link2Feed’s REST API using the same schema to populate client check-ins and the dashboard without impacting the implementation or functionality of the client or admin frontend components.
  4. Integration Tier – Designed as a flexible layer for future features to be implemented. While notification features and SMS/email reminderss were considered and discussed in earlier phases, the current design focuses on CSV workflows and functionalities, while maintaining Link2Feed stadnards for API-readiness and real-tiem admin and client interfaces.

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 and relies only on a temporary operational data storage to manage client check-ins. The system is designed to acts as a real-time pass-through component 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.

 

 design, post 4