Architectural Patterns

We are using a 3-layer architecture consisting the presentation layer, the business layer, Data access layer. The presentation layer is the user interface. The business layer is where the API is kept and the logic of the backend is kept. The Data access layer is where the data is kept.

This allows for us to scale up any single layer when demanded of us. It also allows for the layer to be easily swapped out.

Design Patterns

We are using a template method design pattern for the analyse of the Media Analysis Services. This allows for reusable code and the ease of adding a new service for a new media type in the future since the process is control in the parent class and the order of operation is preserved for all the child classes.

Constraint

The team was limited to $50/month and had to prioritise open-source software.

Architecture diagram

Mapping Quality Requirements to Architectural Decisions

Quality Requirement	Architectural Decision
NF1.1: All sensitive user information that is stored should be encrypted using Blowfish-encryption and should not be transmitted to users or used in URL parameters for any endpoint.	Since the only two layers that have access to the users database is the business layer and data access layer since we are using 3-layer architecture therefore users should not have access to sensitive user information since they are in the presentation layer and only the same layer and the layer above has access to a layer and within the business layer we encrypt the data with Blowfish
NF1.2: Role based access to ensure only authorised users can access sensitive information.	We use JWT to pass the role of the user to the backend where it is validated and then the endpoint checks if the user if authorised to use it
NF2.1: An exception within the backend should not bring the system down and should be thrown as an exception.	We achieve this by using FastApi since FastApi automatically catches any exception that is thrown and sends it as and HTTPException with an http status code 500
NF3.1: New features should be developed and put onto dev within 3 days.	The 3-layer architecture allows for changes to be made within the different layers without having the other layers being affected due to tight coupling
NF4.1: Each page should have a rating of 80% or higher on Google Lighthouse for accessibility.	Since we are using a 3-layer architecture the presentation layer can have changes without affect the raw business logic therefore the pages can be changed until the requirements are met without breaking the other layers
NF5.1: Recovery within 5 minutes of failure	We have auto recovery scripts on the backend deployment

Technology Requirements