Architecture of VS Trivia

From the very first steps in preparing the application, the requirements were clear: design a project that is both scalable and sustainable. It is in this spirit that I envisioned the infrastructure architecture. Whereas for my previous projects with more modest ambitions I opted for a standalone solution hosted on my VPS, this time I chose a distributed approach.

First and foremost, it is essential to review the different software components. On the client side, there are mobile applications (Android/iOS) as well as a web interface intended for administration and users. On the server side, the application consists of an API and a Websocket service.

These two services are deployed in separate Docker containers. Indeed, restarting the Websocket should not render the entire application unavailable, and initially, having all clients connect to the same server simplified data exchanges. This issue does not arise for the API, which is inherently stateless.

These containers run on a Kubernetes instance provided by OVH, distributed over two nodes that host all my active projects (including this blog). However, at this stage, several essential elements are still missing in this quiz application: where to store images, icons, and passwords?

Regarding images, I preferred to host them on an S3 storage space with Digital Ocean, thereby ensuring data persistence without overloading my VPS. Additionally, the VPS also stores the MySQL databases (for the TEST, DEV, and PROD environments). I chose not to externalize this part, as the costs quickly increase when seeking more flexible management, especially concerning the number of active connections. In fact, since I parallelize the retrieval of questions during the quiz schema construction, the number of sessions can quickly exceed 100. To ensure data sustainability, a backup of the production version is performed every night and stored both on my VPS and on the S3 storage, ensuring effective redundancy.

A crucial point concerns access to the Kubernetes clusters via a URL such as api.vstrivia.app. For this, I use my VPS as a proxy with NGINX, which redirects all connections. Additionally, to safeguard against potential DDoS attacks, I employ Cloudflare (free version) to mask the IP address of my VPS.

On the DevOps side, the code is structured around two main branches. The "dev" branch triggers, with each merge, compliance tests and container builds, which are then deployed on the DEV environment of my Kubernetes cluster to test the application in real-world conditions. If all tests pass, the "dev" branch can be merged with the "prod" branch, thereby triggering the production deployment process. The generated containers are then stored in a Container Registry with Digital Ocean.