samyTicketFlowBilletterie cloud-native sur Kubernetes
Une plateforme de billetterie avec réservation de sièges, paiement et billets QR en PDF, découpée en microservices et déployée sur Kubernetes chez Azure. Projet de Mastère en équipe de trois, construit en 48 heures : j'ai porté le back-end, l'infrastructure et la chaîne de livraison.
Le projet
Le sujet imposait de démontrer dix concepts cloud-native sur une application réelle, avec une URL publique, une infrastructure en code et un déploiement continu. Nous avons choisi une billetterie, parce qu'elle concentre les vrais problèmes d'un système distribué : deux personnes qui veulent le même siège, un paiement qui ne répond pas, un billet qui doit être généré une fois et une seule.
SSamy
Back-end, infrastructure, CI/CD
API, worker, passerelle de paiement, Terraform, manifestes Kubernetes, pipelines.
FFayrouz
Front-end
Application React : catalogue, plan de salle, panier, billets.
MMelvin
Documentation et oral
Dossier, script de démonstration, refonte du rendu des billets.
Chiffres tirés du dépôt GitHub.
Architecture
Tout tourne dans un cluster AKS. Traefik reçoit le trafic et l'aiguille vers le front ou l'API ; l'API reste sans état, ce qui permet d'en lancer autant de copies que nécessaire.
L'utilisateur choisit ses sièges : l'API pose un verrou Redis de quelques minutes sur chacun.
Au paiement, l'API appelle la passerelle à travers un disjoncteur, avec délai maximal et repli.
Paiement accepté : l'API publie l'événement reservation.paid dans la file BullMQ.
Le worker génère le QR code et le PDF, les dépose dans le stockage objet, puis acquitte.
L'API sert le PDF et la page de vérification du QR, sans jamais exposer le stockage.
Les patterns, et où ils vivent
Chaque concept est vérifiable dans le code. Voici les plus importants.
Pas de double réservation
Verrou atomique SET NX EX sur chaque siège : le premier gagne, le second reçoit un 409, et le verrou expire seul si l'utilisateur abandonne.
api/src/holds.js
Un paiement lent ne fait pas tomber le site
Disjoncteur opossum avec délai maximal et repli : après trop d'échecs, l'API répond tout de suite au lieu d'empiler les requêtes.
api/src/payment.js
Un message n'est jamais perdu
File BullMQ avec cinq tentatives, attente exponentielle et file des échecs conservée. Le worker n'acquitte qu'une fois le travail fait.
api/src/queue.js · worker/src/index.js
Un billet, une seule fois
Worker idempotent : garde en entrée, ON CONFLICT DO NOTHING et contrainte d'unicité réservation-siège en base.
worker/src/handlers/reservationPaid.js
Une base qui survit aux redémarrages
PostgreSQL en StatefulSet avec volume persistant, service headless et sondes de disponibilité.
infra/k8s-aks/ticketflow.yaml
Prêt pour la production
Routes /healthz et /readyz, journaux structurés pino, arrêt propre sur SIGTERM, sondes Kubernetes partout.
api/src/health.js · server.js
Choix assumés
Trois décisions défendues devant le jury plutôt que subies.
01AKS plutôt qu'Azure Container Apps
Container Apps masque Kubernetes. Un vrai cluster permettait de démontrer StatefulSet, Ingress, sondes et haute disponibilité. En contrepartie, un coût à surveiller et un repli sur minikube prévu pour la démo.
02PostgreSQL dans le cluster
Plutôt qu'une base managée : le pattern StatefulSet et volume persistant devient concret, et l'infrastructure reste simple à reproduire.
03Billets servis par l'API
Le stockage objet reste privé. Les PDF passent par une route authentifiée au lieu d'une URL de stockage exposée : meilleure posture de sécurité.
Livraison
Terraform provisionne le groupe de ressources, le registre d'images, le cluster AKS, le stockage et le coffre de secrets. À chaque push sur main, GitHub Actions construit et publie les quatre images, puis met à jour le cluster.
- 22 juin 2026Squelette et infrastructure
Monorepo, services, manifestes Kubernetes, Terraform pour Azure.
- 23 juin 2026Déploiement continu et audit
Pipeline de déploiement activé, audit de conformité qui relève deux défauts bloquants avant la démo, corrigés dans la foulée.
- 24 juin 2026Démonstration
Guide de déploiement, script de démo : un commit en direct part en production pendant la soutenance.
- Terminé, juin 2026Résultat
Les dix concepts attendus démontrés par du code vérifiable, une démo de bout en bout, et un dépôt documenté (architecture, contrat d'API, ADR, guide de déploiement).
Pas besoin de compte Azure pour l'essayer : tout le projet se lance en local avec une seule commande, docker compose up.