**ReCodEx** is designed to be very modular. **WebApp** is considered to be frontend part of whole system while all other parts/services are considered to be backend part. **WebApp** contains almost all logic of the app including _user management and authentication_, _storing and versioning files_ (through connection with **Fileserver**), _counting and assigning points_ to users etc. **WebApp** is connected with **Broker**, **Fileserver** and partially with **Monitor**. **Broker** is essential part of whole architecture and can be marked single point of failure.
Almost whole communication goes through **Broker** and `ZeroMQ` messaging middleware. When **WebApp** wants to execute submission then all datas are handed over to **Worker** through **Broker**, similar situation is with progress state which start in **Worker** goes through **Broker** then pass **Monitor** and end up in **WebApp**. Only part of communication, which does not include **Broker**, is communication with **Fileserver** which is realized through `HTTP` commmunication. This communication can be initiated by **WebApp** or by **Worker**, other services have no access to **Fileserver**. Summarize of above stated can be found in overall architecture image (green arrows = `HTTP` communication, red arrows = communication through `ZeroMQ`).
**Worker's** main role is securely _compile_, _run_ and _evaluate_ given submit against model solutions provided by author of each task. It is logicaly divided into three objects:
- **Message Frontend** communicates with **WebApp** using messaging queue [ZeroMQ](http://zeromq.org/). It receives new submits, operates the evaluation through **Work API** and reports progress back.
Picture below is overall internal architecture of worker, which shows its defined classes with private variables and public functions. Vector version of this picture is available [here](https://github.com/ReCodEx/GlobalWiki/raw/master/images/Worker_Internal_Architecture.pdf).
To meet these requirements, **Storage** and **Database** must be set as bellow.
### Storage
**Storage** is meant as disc space with some commonly used filesystem. We'll use `ext4`, but the other ones should work too. **Storage** file structure is:
- **temp** directory is dedicated to temporary storing outputs of programs on teachers' demand. This directory will be erased by cron job on daily basis.
### Database
For user friendly access and modifying tasks following information should be stored in database:
- list of tasks with their newest version number
- for every task and version list of used files (their hashed names)