CSSE6400

CoughOverflow

Software Architecture

Semester 1, 2025

Summary

In this assignment, you will demonstrate your ability to design, implement, and deploy a web API that can process a high load, i.e. a scalable application. You are to deploy an API to analyse images of saliva samples to identify if a patient has COVID-19 or avian influenza (H5N1), which is commonly called bird flu. Specially your application needs to support:

• Analysing an image received via an API request.

•  Providing access to a specified REST API, e.g. for use by front-end interfaces and other applications.

•  Remaining responsive while analysing images.

Your service will be deployed to AWS and will undergo automated correctness and load-testing to ensure it meets the requirements.

1 Introduction

For this assignment, you are working for CoughOverflow, a new UQ start-up.  CoughOverflow uses ma- chine learning techniques developed by QDHeC to analyse images of saliva samples. The analysis is able to identify if an individual is infected with one of a few pathogens. The initial service focuses on identifi- cation of COVID-19 or H5N1, due to their current level of risk to the public.

Task CoughOverflow uses a microservices architecture to implement their analysis platform. The CTO saw on your resume that you are taking Software Architecture and has assigned you to design and imple- ment the pathogen analysis service. This service must scale to cope with the anticipated large number of tests.

Requirements Automated identification of pathogens is an important service.  Manual testing by lab technicians is labour intensive and time consuming.  Automated tests free lab technicians for more im- portant work, and provide faster responses to healthcare staff. This is critical in an epidemic or pandemic scenario, when tens or hundreds of thousands of tests need to be performed daily.

CoughOverflow’s pathogen analysis service (PAS) needs to be designed to scale to match demand. Pathology labs will obtain saliva samples from patients.  The labs will create images of the cells in the samples. These images will be sent to the PAS for analysis.

The algorithms used to analyse the images are computationally intensive.  It is not possible to return a result immediately for a submitted image.  Labs, or other healthcare providers, will need to query the PAS to obtain results at a later time. Results can be queried for a single test, or a batch of tests for a lab or patient.

As COVID-19 and H5N1 are potentially life threatening to some patients, the service must be able to provide test results in a timely manner. Early treatment and effective isolation practices can significantly reduce the impacts of these diseases, as well as reducing strain on healthcare resources.

Persistence is an important characteristic of the platform.  Resubmitting analysis requests due to lost data would place unnecessary strain on pathology labs, at times when they may be under extreme pressure to deliver results.  Upon receiving an analysis request, and after error checking, the PAS must guarantee that the data has been saved to persistent storage before returning a success response.

2 Interface

As you are operating in a microservices context, other service providers have been given an API specifi- cation for your service. They have been developing their services based on this specification so you must match it exactly.

The interface specification is available to all service owners online:

https://csse6400.uqcloud.net/assessment/coughoverflow

3    Implementation

The following constraints apply to the implementation of your assignment solution.

3.1    Analysis Engine

You have been provided with a command line tool called overflowengine that must be used to analyse sample images. This tool was developed by AI and medical researchers at QDHeC. The tool has varying performance, due to how clear the pathogen markers are in the cell sample images. You will have to work around this bottleneck in the design and development of the PAS.

Your service must utilise the overflowengine command line tool provided for this assignment. The compiled binaries are available in the tool’s GitHub repository:

https://github.com/CSSE6400/CoughOverflow-Engine.

Warning

You are not allowed to reimplement or modify this tool.

The analysis engine requires pre-processing of cell sample images to highlight pathogen markers. This pre-processing is done by the pathology labs.  For testing purposes, you must use the sample images provided in the analysis engine’s repository. If you try to generate your own images, they are likely to fail analysis or give false results.

3.2    AWS Services

Please make note of the AWS services that you can use in the AWS Learner Lab, and the limitations that are placed on the usage of these services. To view this page you need to be logged in to yourAWS Learner Lab environment and have a lab open.

3.3 External Services

You may not use services or products from outside of theAWS Learner Lab environment. For example, you may not host instancesofthe overflowengine command line tool on another cloud platform (e.g. Google Cloud).

You may not use services or products that run on AWS infrastructure external to your Learner Lab environment. For example, you may not deploy a third-party product like MongoDB Atlas on AWS and then use it from your service.

You may not deploy machine learning or GPU backed services.

4    Submission

This assignment has three submissions.

1. April 4th – API Functionality

2.  April 17th – Deployed to Cloud

3.  May 9th – Scalable Application

All submissions are due at 15:00 on the specified date. Your solution for each submission must be com- mitted and pushed to the GitHub repository specified in Section 4.3.

Each submission isto be in its own branch. You must use the branch names exactly as indicated below. Failure to use these branch names may result in your submission not being marked, and you obtaining a grade of 0 for the submission.

• stage-1 for API Functionality, due on April 4th

• stage-2 for Deployed to Cloud, due on April 17th

• stage-3 for Scalable Application, due on May 9th

When marking a stage, we will checkout the branch for that stage.  Any code in the main branch or any other branch, will be ignored when marking. We will checkout the latest commit in the branch being marked. If the commit date and time is after the submission deadline, late penalties will be applied, unless you have an extension. Late penalties are described in the course profile.

Note: Experience has shown that the large majority of students who make a late submission, lose more marks from the late penalty than they gain from any improvements they make to their solution. We strongly encourage you to submit your work on-time.

You should commit and push your work to your repository regularly.  If a misconduct case is raised about your submission, a history of regular progress on the assignment through a series of commits could support your argument that the work was your own.

Extension requests must be made prior to the submission deadline via my.UQ.

Your repository must contain everything required to successfully deploy your application.

4.1    API Functionality Submission

Your first submission must include all of the following in your repository:

•  Docker image (Dockerfile) of your implementation of the service API, including the source code and a mechanism to build and run the service.

• A local . sh script. that can be used to build and run your service locally. This script. must be in the root directory of your repository. The local . sh script must launch your container with port 8080 being passed from the container to the testing environment, and your service must be available at http://localhost:8080/.

We will run a suite of tests against your API at this URL.

4.2    Deployed to Cloud & Scalability Submissions

The second and third submissions must include all of the following in your repository:

• Your implementation of the service API, including the source code and a mechanism to build the service.

• Terraform. code that provisions your service in a fresh AWS environment.

• A deploy . sh script. that uses your Terraform code to deploy your application.  This script. must be in the root directory of your repository.  This script may perform other tasks as required by your implementation.

When deploying your second and third submissions to mark, we will follow reproducible steps, outlined below. You may re-create the process yourself.

1. Your Git repository will be cloned locally. The submission branch will be checked out.

2. AWS credentials will be copied into your repository in the root directory, in a file called credentials.

3. The script. deploy . sh in the root directory will be run.

4. The deploy. sh script. must create a file named api. txt, which contains the URL at which your API is deployed, e.g. http://my-api. com/ or http://123.231.213.012/.

5. We will run automated functionality and load-testing on the URL provided in the api . txt file.

Important Note: Ensure your service does not exceed the resource limits of AWS Learner Labs. For exam- ple, AWS will deactivate your account if more than fifteen EC2 instances are running. If you use up your allocated budget in the Learner Lab, you will not be able to run any services.

4.3    GitHub Repository

You will be provisioned with a private repository on GitHub for this assignment, via GitHub Classroom. You must click on the link below and associate your GitHub username with your UQ student ID in the Classroom.

https://classroom.github.com/a/o7GwUHX6

Associating your GitHub username with another student’s ID, or getting someone else to associate their GitHub username with your student ID, is academic misconduct.

If for some reason you have accidentally associated your GitHub username with the wrong student ID, contact the course staff as soon as possible.