HayaDev
APIIn development

KeepGames API

Multi-tenant API for a SaaS platform of therapeutic biofeedback games, built at Self Aplicações Tecnológicas para Saúde, Educação e Bem-Estar.

  • TypeScript
  • NestJS
  • PostgreSQL
  • TypeORM
  • AWS
  • Stripe

This project is covered by confidentiality. The page describes only the technical nature of the work, with no internal details, data or proprietary code.

About the project

KeepGames API is the backend of a SaaS platform of therapeutic biofeedback games, responsible for managing organizations, patients, professionals, game sessions, telemetry, forms and subscriptions.

I worked on the development of the API and the data model, including defining the business rules and the integrations the platform’s different clients need.

Key technical challenges

  • Multi-tenant architecture, with data isolated between organizations.
  • Authentication and authorization for different kinds of clients.
  • Secure communication between the portal and the games.
  • Recording and storing the physiological telemetry tied to each match.
  • Data modelling for large volumes of game records.
  • Separating transactional data from telemetry data.
  • Configurable, versioned forms.
  • Business rules for subscriptions and access control.
  • Stripe integration for payments and subscriptions.
  • Idempotent operations and transactional consistency.
  • Automated tests for business rules and critical flows.

Architecture

The API was built with NestJS, TypeORM and PostgreSQL, using a modular architecture organized around the application’s domains.

Business rules are centralized in the backend, keeping the clients — the portal and the games — as consumers of a single, controlled API.

The data model was designed to preserve the integrity of historical records and to let the games evolve without excessive coupling between their specific structures.

Data and telemetry

One of the project’s main challenges was handling match data tied to physiological signals.

The architecture separates transactional data from telemetry, so large volumes of raw data can be stored without affecting the application’s everyday queries.

The information needed for listings and general analysis is kept in an optimized form, avoiding loading the raw data when it is not needed.

Engineering

During development, I worked mainly with:

  • relational modelling;
  • business rules;
  • multi-tenancy;
  • authentication and authorization;
  • transactional consistency;
  • idempotency;
  • data versioning;
  • integration with external services;
  • telemetry processing;
  • unit and integration tests;
  • AWS infrastructure.

What this project demonstrates

This project brings together engineering problems common to real SaaS products: data isolation, security across different clients, large volumes of telemetry, evolving data models, external integrations and consistent business rules.

Confidential project. The information presented has been deliberately limited to general technical aspects, without exposing code, user data or internal product details.

The project is still in development.

Back to projects