Architectural Overview

This page describes the architectural overview of the CAFF store.

General architecture

The CAFF store generally has the following architecture:

• First and foremost, the data related to the application is stored in a database. The database is a MySQL instance. We chose it for its wide functionality and available support.
• Then, the next layer is the server layer. The server is responsible for implementing the business logic of the application. It consists of two main components:
  • It consists of a Spring server that exposes an HTTP REST API and communicates with the database using the jdbc driver (see more in Server Side).
  • And it consists of a separated native component, that is responsible for parsing the CAFF files and communicates with the Spring component via GRPC. (see more in Native Component)
• The next layer is a reverse proxy and load balancer that is responsible for serving as an endpoint to the clients. Moreover, this layer enables the SSL encryption of the REST API.
• Finally, there is an Android client application that provides an interface for the user to use the CAFF store.

Security considerations

The public entrypoint for the server is the reverse proxy. After the reverse proxy, the encryption is removed from the communication, so countermeasures should be taken, so the inner network is not accessible by attackers.

From security point of view, the native component should be given more care, as it is implemented in a native language, thus it might be susceptible to different type of attacks (buffer overflow, etc...).

Thereby, the native component should be separated from the Spring server and the database. This way, should the native component become compromised, and should the attackers gain control over it, they will not be able to read the memory of the server and database which might contain sensitive data. Similarly, the network on which the native component communicates with the Spring server should be distinct from the networks on which the Spring server communicates with either the database or the reverse proxy.

Deployment via Docker

To satisfy the requirements above, the server side of the application can be deployed via docker the following way:

• Containers
  • The reverse proxy should be a container capable of satisfying the jobs of a reverse proxy (e.g. traefik)
  • The CAFF store, the Spring server should be a container running the server.
  • The CAFF parser, the native component should be a container running the parsing process isolated from the rest of the components.
  • The database should be a container.
• Networks
  • The reverse proxy and the CAFF Store should communicate over a dedicated network.
  • The CAFF Store, and the native component should communicate over a dedicated network.
  • The CAFF Store, and the database should communicate over a dedicated network.

Scaling the server side

The server side is generally stateless, which makes it easy to scale the server horizontally.

In this instance the reverse proxy is expected to behave as a load balancer as well to forward the requests to the CAFF Store instances. Each CAFF Store instance should have a dedicated native component on a dedicated network.

Finally, the server instances should communicate with the same database instance as transactions are required. Note, that MySQL has its own infrastructure and ways to scale horizontally, independently of the server.