Architecture

The Ocapi system needs these different parts to work properly:

• the Ocapi backend application
• a local Redis database
• a storage server like Amazon S3
• the frontend Javascript payload, hosted on a CDN

One of the main concept of Ocapi is resilience: each server is independent from the others. They all hold the same configuration and can generate similar challenges to users.

Ocapi Backend

We use Flask for the backend. It is the link between the database and the frontend. It generates the challenges and verifies them. It will create challenges according to the mode mentioned in a configuration file.

The backend is configured using a read-only file, no configuration is ever stored in the database.

Database

We use Redis for the database. It is more used as a cache than a database. It is therefore not intended to last and must be emptied and populated regularly. The database is built from a configuration file and Arkindex data.

Each challenge response provided by users is collected regularly and stored in a persistent database, not exposed to the public Ocapi interfaces.

You can view this database as a warm cache of challenges and user answers.

Storage server

Two store the images related to the challenge we use a Amazon S3 compatible server. When importing data from Arkindex, the images are stored in the bucket specified in the configuration file. The frontend uses the server to fetch the images corresponding to the challenges.

This removes a lot of load on the backend system, as it's only responsible for challenge creation and validation.

Frontend

The frontend displays the data provided by the backend. It adapts itself according to the type of challenge chosen.

The partner website embed our Javascript payload: this is what the end user will see.