System Architecture
The major Marsad services, their responsibilities, and how work moves between them.
System Architecture
Marsad's operational product consists of the Web App and Model Server. The Web App owns the user and administrator experience and the application database; the Model Server owns processing and collection work. They communicate through HTTP APIs, Redis-backed RQ queues, and a shared-data directory mounted into both services.
These diagrams describe the implementation currently wired by the root Compose files and the two service codebases. They intentionally show service boundaries and data movement, not every route or model.
C4 Level 1 — System Context
This view places Marsad in its wider operating environment. It identifies the people who use or administer the system and the external services Marsad relies on to collect data, run analysis, deliver realtime updates, and send notifications.
C4 Level 2 — Containers
This view zooms into the Marsad deployment to show its main runtime containers and how they collaborate. It highlights the Web App, Model Server, queue workers, database, and shared storage, along with the HTTP, queue, and file-based connections between them.
Service Responsibilities
| Container | Repository / runtime | Responsibility |
|---|---|---|
| Web App | main/ | User and admin workflows, authentication, API routes, PostgreSQL records, uploads/downloads, and job tracking. |
| Model Server | model-server/ | Flask API for analysis, collection, reporting, and status integration. |
| RQ Workers | model-server/ image | Executes queued analysis, Tanbih, notification, and data-collection work. |
| Redis | Root Compose service | Backs the RQ queues used by Model Server workers. |
| Shared data | main/shared-data mounted at /app/shared-data | Carries datasets and generated files between the Web App, Model Server, and workers. |
Main Data Flow
The Web App creates and tracks application records in PostgreSQL. It sends collection, analysis, and analytics requests to the Model Server over HTTP. The Model Server queues asynchronous work in Redis, and the relevant RQ worker reads input files from shared data and writes generated output there. Workers send job-status updates back to Web App API routes; the Web App persists the result and can notify the requesting user.
For the verified workflows, see Data Flows. See Cross-Repository Contracts before changing a boundary shared by these services.