System Architecture Overview

This page provides a high-level overview of EduSwap’s system architecture for school due diligence, Department review and vendor assessment purposes.

It describes the platform’s major components, trust boundaries, data flows and deployment approach in a way intended to support ICT, security and procurement review.

It is a high-level architecture summary rather than a low-level infrastructure or port-level specification.

EduSwap is designed as a cloud-hosted, multi-tenant SaaS platform with a browser-based client, a secure backend entry layer, application services, a data access layer and segregated data storage.

Selected third-party services may support identity, payments and email or notification delivery.

Core data handling is intended to remain within an Australian-hosted cloud environment.

Client layer: school users access EduSwap through a modern web browser, with core interaction occurring in the browser over encrypted connections.

API gateway or backend entry point: requests are intended to pass through authentication, authorisation, routing, input validation and rate-limiting controls.

Application services layer: domain logic is intended to handle listings, users and school organisations, transactions and related business rules.

Data access layer: repository or ORM-style access patterns are intended to enforce consistent authorisation and tenancy behaviour before data operations occur.

Data layer: structured data, object storage and logging or metrics services are intended to support platform operation, evidence and observability.

External integrations: identity, payment and notification services may be connected through controlled credentials and encrypted service communication.

All traffic between school users and the platform is intended to be encrypted using HTTPS with TLS protections.

A clear trust boundary is intended to exist between the public internet and the secured cloud environment.

Tenant-aware logic, role-based access control and school-linked authorisation checks are intended to prevent one school accessing another school’s private information.

Administrative tools are intended to remain protected within the same secure environment with stronger access requirements such as MFA and least-privilege access.

Core production data, including databases, files, backups and logs, is intended to be stored within Australian data centres.

The platform is intended to avoid deliberate overseas storage or replication of core school data.

Regional deployment decisions may vary between supported Australian cloud regions depending on operational needs.

A school user signs in using a school email address and, where supported, optional single sign-on pathways.

The browser sends authenticated HTTPS requests to the backend entry layer.

The backend is intended to validate the request, apply security checks and route it to the relevant application service.

Application services evaluate business rules and interact with the data access layer for reads and writes.

Structured data and stored files are retrieved or updated through controlled storage services.

Audit logs and observability records may be written asynchronously to support review, security and reliability.

This architecture overview is intended to help ICT, security, risk and procurement teams understand EduSwap’s logical structure and trust model.

A more detailed component inventory or low-level technical description may be prepared later where required for formal vendor onboarding or Department assessment.

This page should be read together with the Security & Infrastructure Statement and Cybersecurity Controls Matrix.