Étude de cas · Marketplace d'enchères live

Blisterr

En cours · depuis 2026

Marketplace d'enchères en direct pour objets de collection : le vendeur anime un live, les acheteurs enchérissent en temps réel. On a repris l'app Flutter et le backend existants pour en livrer une version plus rapide, portée par une architecture de streaming hybride LL-HLS + LiveKit et une infrastructure de diffusion provisionnée à la demande, dimensionnée live par live.

Contexte

Marketplace d'enchères live pour cartes TCG, figurines et objets de collection. Le vendeur lance un live, les acheteurs enchérissent en direct sur chaque lot. Le studio a repris une app Flutter et un backend déjà en production pour en livrer une version plus rapide, sans jamais couper le service.

Le défi

Refondre une base existante lourde tout en gardant le produit en ligne. Côté app : 237 StatefulWidgets à migrer vers des hooks et Riverpod, 93 StateNotifiers à passer en codegen @riverpod, l'injection GetIt à supprimer, la navigation à basculer sur GoRouter — environ 2 500 fichiers touchés. Côté backend : sortir de MongoDB pour PostgreSQL sans fenêtre de coupure. Et faire tenir un live vidéo interactif sous les 3 secondes de latence sans exploser la facture cloud.

Notre approche

Migration progressive en Strangler Fig sur les deux fronts. L'app Flutter passe intégralement en hooks + Riverpod avec providers générés par codegen, DI GetIt retirée, navigation GoRouter — le tout par vagues, produit toujours en production. Le backend migre de MongoDB vers PostgreSQL 17 via Prisma, table par table. Côté diffusion, une architecture hybride LL-HLS + LiveKit tient la latence sous 3 secondes, portée par une infrastructure de diffusion provisionnée à la demande, dimensionnée live par live pour suivre la charge — ce qui divise le coût par viewer-heure par environ 6 face à une stack full WebRTC. Le backend est couvert par 6 680 tests, 97 % de couverture.

Stack technique
FlutterNestJSPostgreSQLLiveKitLL-HLSHetznerCloudflare
Résultat

En production depuis 2026, en itération continue. Coût par viewer-heure divisé par 6 versus une stack WebRTC pure. Latence maintenue sous 3 secondes côté viewers.