Ce que l'architecture cherche à garantir
Une plateforme claire à utiliser, solide à faire évoluer.
Front
Nuxt 4 + Vue 3 + TS
Back
Go + Gin + GORM
Messaging
NATS JetStream
Infra
K8s + Traefik + CNPG
Architecture publique
Comment fonctionne otux
otux est pensé comme une plateforme de progression technique avec mentorat, missions, labs, crédits et communauté. Cette page explique les grands choix de stack, d'infrastructure et d'architecture qui font tourner l'expérience.
Progression guidée
La plateforme est pensée pour accompagner un parcours complet : diagnostic, plan de progression, missions, labs, crédits et mentorat.
Une base de code cohérente
Le projet repose sur un front Nuxt 4 et un backend Go organisé par domaines métier pour garder une architecture claire, lisible et évolutive.
Traitements synchrones et asynchrones
Les actions simples passent par l'API. Les traitements plus longs ou critiques s'appuient sur des événements durables et des workers spécialisés.
Fiabilité et traçabilité
Les crédits, les bookings, les notifications et les intégrations externes sont pensés pour rester auditables, résilients et récupérables.
Du navigateur jusqu'aux traitements de fond
otux ne repose pas sur une seule couche. Le front pilote l'expérience, l'API centralise les règles de passage, et les services de fond prennent en charge les traitements plus longs, les intégrations et les projections de lecture.
1
Une interface web rapide et lisible
Le site public et l'espace connecté sont construits avec Nuxt 4, Vue 3 et TypeScript. L'objectif est de garder une expérience fluide, SSR-friendly et simple à faire évoluer.
2
Une API Go pour les commandes utilisateur
Le backend Go expose une API Gin stateless. Elle centralise l'authentification, les permissions, la validation HTTP et les contrats de données de la plateforme.
3
Un backbone evenementiel pour les flux longs
Quand une action demande plus qu'une simple lecture ou écriture immédiate, elle peut être relayée sur NATS JetStream pour être traitée par le bon rôle applicatif.
4
Des workers specialises par responsabilite
Booking, billing, notifications, Discord, transcription, labs et projections peuvent être traités par des workers dédiés, sans charger inutilement l'API publique.
5
Des donnees autoritatives et des vues de lecture
PostgreSQL reste la base de vérité pour les données métier. Certaines vues sont matérialisées pour l'UX, mais elles restent recalculables à partir des sources autoritatives.
Stack logicielle
Les briques techniques principales
La stack a été choisie pour garder un bon équilibre entre lisibilité de la codebase, capacité d'évolution et robustesse en production.
Frontend
- Nuxt 4 pour le rendu web et la structure applicative
- Vue 3 avec TypeScript pour des pages et composants fortement typés
- Tailwind CSS pour un système UI réutilisable et rapide à faire évoluer
- Composables Nuxt pour organiser l'accès aux données et aux workflows
Backend
- Go pour un backend stateless et modulaire
- Gin pour l'API HTTP
- GORM et SQL pour la persistance applicative
- Swagger pour documenter les contrats d'API
Infra & data
- PostgreSQL via CloudNativePG pour les données métier et les projections
- NATS JetStream pour les commandes, événements et traitements asynchrones
- Kubernetes sur GOInfra avec Traefik en entrée réseau
- GitLab CI/CD et Harbor pour construire, publier et déployer les versions
Architecture de code
Des domaines métier plutôt qu'un bloc unique
Le backend est organisé par slices métier. Cela permet de faire vivre auth, onboarding, plans, missions, crédits, sessions, IA, communauté ou labs avec une responsabilité plus nette dans la codebase.
authuserslearnersdiagnosticsplansmissionsresourcesseasonscreditsbillingcommunitysessionslabsaitranscriptsprojectionticketsledgerdbobservabilityobjectstorageetc.
Rôles d'exécution
Un même socle, plusieurs rôles spécialisés
Le projet peut être déployé avec plusieurs rôles applicatifs à partir du même socle technique. Cela permet de faire évoluer l'API, les workers, la transcription, les notifications ou les labs selon la charge réelle.
webapicommand-ingestworkerbilling-workercommunity-workernotification-workerdiscord-bottranscript-workerlab-controllerledgerschedulerprojection-worker
Principes structurants
Pourquoi cette architecture a été retenue
Monolithe modulaire distribué
Le backend reste une seule codebase Go, mais le même binaire peut être lancé selon plusieurs rôles. Cela simplifie le développement tout en permettant de scaler certains traitements indépendamment.
Séparation commande / traitement / projection
Les actions critiques peuvent être acceptées rapidement, traitées de façon fiable en arrière-plan, puis exposées via des read models adaptés à l'interface.
Composants stateless
L'état critique ne dépend pas de la mémoire d'un seul processus. Cela facilite les redémarrages, le scaling horizontal et la reprise sur incident.
Crédits auditables
Les crédits IA, labs et mentor reposent sur une logique de ledger append-only (type "blockchain", immuable) afin de garder un historique fiable, explicite et vérifiable dans le temps.
Fiabilité
Ce qui est surveillé et protégé
L'architecture ne sert pas seulement à organiser le code. Elle doit aussi rendre la plateforme plus stable, plus observable et plus simple à faire reprendre en cas de pic de charge ou d'incident externe.
Idempotence et reprise
Les intégrations sensibles comme les webhooks ou certains traitements asynchrones sont conçues pour tolérer les replays, les doublons et les reprises après incident.
Observabilité
Logs structurés, métriques Prometheus et traces OpenTelemetry aident à suivre les flux importants et à diagnostiquer un problème plus vite.
Sécurité applicative
Authentification via fournisseur externe, RBAC côté backend, validation stricte des entrées et protection des appels sensibles font partie du socle technique.
Scalabilité par rôle
L'API, les workers, les intégrations Discord, la transcription ou les labs peuvent évoluer selon leur propre charge au lieu d'imposer une architecture monolithique rigide.