ITR Design

The ITR is designed from the ground up as a secure multi-tenant system for high system loads.

This has lead to the following choices :

• every customer has their own database. This will increase performance and most importantly security
• central information is placed and maintained in the master database which is a central database. Some information like tests, reports et cetera can be place in this central database so that all tenants/customers can potentially make use of it
• processing is taken away from the central server as much as possible. The central server is responsible for : serving the website, storing and retrieving data, providing central server functions which cannot be executed from the browser (like sending mails). The central server is also responsible for serving ONLY the proper data to the webbrowser. This means for example that a test taking user can NOT access all information in the system. And as another example an office user can read and use test definitions but ONLY a test author can update the test defitions
• The API is split into TWO APIs. The internal API which is for usage only by the ITR webbrowsers and the external API which can be used by basically any calling system. If you do not want external API functionality then simply do not install it.
• All API calls are made to do whatever they need to do, but they are designed for short run times and high concurrency. THis means that a webbrowser potentailly will have to make many calls to complete a function, but this does NOT block all the other web browsers

The website, internal API and external API can be placed on the same server or computer in its most simple form. They can also be installed and used in for example docker containers, in a docker swarm or kubernetes cluster, or in a load balanced server cluster. The conditions are the following.

• THe instance folder needs to be shared between all API containers (both internal and external)
• The database needs to be accessible for all API containers
• The internal API container needs to be on the same domain name for CORS checks by the browser.

The database back end is postgres. You can setup a read only postgres copy on each API server if required for scaling out. Please note that test run users mostly write to the database while taking tests. Office users tend to have a higher read behaviour.