Médias, jeux et temps réel
Du temps réel sans file d'attente, du débit équitable.
Flux SSE et WebSocket relayés sans retenue, débit par appelant et refus explicites : une audience qui afflue ne fait pas tomber les services, et chaque joueur ou lecteur garde sa part. C'est la passerelle de notre plateforme de tournois.
Ce que Flexway décide, chez vous
Qui appelle, ce que Flexway décide, ce qui est appelé : chaque trajet est un cas d'usage de votre secteur. En pointillé, ce qui est à venir.
Architecture pour les médias et le jeu : les joueurs, les spectateurs et les applications mobiles passent par Flexway, dans votre infrastructure. Flexway accepte des comptes de plusieurs fournisseurs, relaie les flux SSE et WebSocket, publie sur le courtier un événement reçu en HTTP et tient le débit de chaque joueur, devant vos serveurs de jeu, la diffusion en direct et Kafka. Un joueur au-delà de son débit reçoit un 429. À venir : HTTP/3 côté appelant.
- Joueurs
- Les joueurs : un débit par joueur protège vos serveurs de jeu, avec Retry-After quand la limite est atteinte.
- Spectateurs
- Les spectateurs d'une diffusion : flux SSE ou WebSocket relayés sans retenue et drainés proprement à l'arrêt.
- Apps mobiles
- Les applications mobiles de vos utilisateurs : leurs appels passent par Flexway, avec le même contrat et la même identité que le web.
- HTTP/3 côté appelant
- Prévu : Flexway acceptera HTTP/3 du côté des appelants (QUIC), en plus des versions actuelles.
- Comptes multi-fournisseurs
- Flexway vérifie qui appelle (jeton OIDC, clé d'API ou certificat client) et lit le tenant dans l'identité ; sans identité valide : 401.
- Débit par joueur
- Un seau à jetons par appelant limite son débit ; au-delà : 429 avec Retry-After et les en-têtes RateLimit.
- Événement publié depuis HTTP
- Flexway publie sur votre courtier, sous contrat AsyncAPI et en enveloppe CloudEvents, ce qu'il reçoit en HTTP.
- Flux SSE, WebSocket
- Les flux temps réel (SSE, WebSocket) sont relayés sans retenue ; l'identité et le débit sont vérifiés à l'ouverture.
- Serveurs de jeu
- Vos serveurs de jeu : protégés par un débit par joueur.
- Diffusion en direct
- Votre diffusion en direct : flux relayés sans retenue jusqu'aux spectateurs.
- Kafka
- Votre cluster Kafka : Flexway y publie les événements reçus en HTTP, sous contrat, en enveloppe CloudEvents.
- Ligne : un trajet
- Correspondance : décision partagée
- Requête
- Événement
- Refus
- Votre infrastructure
- Prévu
- HTTP/3 côté appelantprévu
- Comptes multi-fournisseursplusieurs émetteurs OIDC
- Débit par joueurseau à jetons, Retry-After
- Événement publié depuis HTTP202, posé sur le courtier
- Flux SSE, WebSocketsans retenue, drainés à l'arrêt
1Un spectateur suit une partie en direct
Ce que Flexway décideLe flux SSE ou WebSocket est relayé tel quel ; à l'arrêt d'une réplique, il est drainé.
Ce qui est protégéPas de coupure du direct pendant un déploiement.
2Un joueur publie un événement de jeu
Ce que Flexway décideLa requête HTTP devient un événement sur le courtier ; le client reçoit un 202.
Ce qui est protégéVos serveurs de jeu consomment à leur rythme.
3Un client envoie trop de requêtes
Ce que Flexway décideLe seau à jetons s'applique par joueur ; au-delà, un 429 avec Retry-After.
Ce qui est protégéLe débit reste équitable entre joueurs.
Joueurs
Les joueurs : un débit par joueur protège vos serveurs de jeu, avec Retry-After quand la limite est atteinte.
Trajets qui passent ici
Spectateurs
Les spectateurs d'une diffusion : flux SSE ou WebSocket relayés sans retenue et drainés proprement à l'arrêt.
Trajets qui passent ici
Apps mobiles
Les applications mobiles de vos utilisateurs : leurs appels passent par Flexway, avec le même contrat et la même identité que le web.
Trajets qui passent ici
HTTP/3 côté appelant
Prévu : Flexway acceptera HTTP/3 du côté des appelants (QUIC), en plus des versions actuelles.
- Fonctionnalités du catalogue
- HTTP/3 côté appelant
Comptes multi-fournisseurs
Flexway vérifie qui appelle (jeton OIDC, clé d'API ou certificat client) et lit le tenant dans l'identité ; sans identité valide : 401.
- Décision
- plusieurs émetteurs OIDC
- Fonctionnalités du catalogue
- iss et aud vérifiés ; plusieurs émetteurs dans une même configuration ; Validation JWT, clés JWKS en cache avec rotation
Trajets qui passent ici
Débit par joueur
Un seau à jetons par appelant limite son débit ; au-delà : 429 avec Retry-After et les en-têtes RateLimit.
- Décision
- seau à jetons, Retry-After
- Fonctionnalités du catalogue
- Débit par appelant (seau à jetons) ; 429 avec Retry-After et en-têtes RateLimit
Trajets qui passent ici
Événement publié depuis HTTP
Flexway publie sur votre courtier, sous contrat AsyncAPI et en enveloppe CloudEvents, ce qu'il reçoit en HTTP.
- Décision
- 202, posé sur le courtier
- Fonctionnalités du catalogue
- Médiation de la frontière synchrone vers asynchrone ; Publication Kafka sous contrat, enveloppe CloudEvents
Trajets qui passent ici
Flux SSE, WebSocket
Les flux temps réel (SSE, WebSocket) sont relayés sans retenue ; l'identité et le débit sont vérifiés à l'ouverture.
- Décision
- sans retenue, drainés à l'arrêt
- Fonctionnalités du catalogue
- Flux relayés sans retenue : SSE et corps fragmentés ; WebSocket relayé ; Arrêt gracieux : les flux en cours sont drainés
Trajets qui passent ici
Serveurs de jeu
Vos serveurs de jeu : protégés par un débit par joueur.
Trajets qui passent ici
Diffusion en direct
Votre diffusion en direct : flux relayés sans retenue jusqu'aux spectateurs.
Trajets qui passent ici
Kafka
Votre cluster Kafka : Flexway y publie les événements reçus en HTTP, sous contrat, en enveloppe CloudEvents.
- Fonctionnalités du catalogue
- Publication Kafka sous contrat, enveloppe CloudEvents
Trajets qui passent ici
Ce que le secteur exige
- DiffusionDes flux sans retenue
- SSE et WebSocket relayés tels quels ; à l'arrêt d'une réplique, les flux en cours sont drainés.
- ÉquitéUn débit équitable par joueur
- Seau à jetons par appelant ; au-delà, un 429 avec Retry-After plutôt qu'une file sans fin.
- ComptesDes comptes de plusieurs fournisseurs
- Plusieurs émetteurs OIDC à la fois, clés de signature en cache avec rotation.
- Événements de jeuDes événements publiés depuis HTTP
- Un client publie un événement en HTTP ; la passerelle le pose sur le courtier et répond 202.
Comment Flexway y répond
Des flux sans retenue
- Flux relayés sans retenue : SSE et corps fragmentésLivré · v0.1.0
- WebSocket relayéLivré · v0.1.0
- Arrêt gracieux : les flux en cours sont drainésLivré · v0.1.0
Un débit équitable par joueur
- Débit par appelant (seau à jetons)Livré · v0.1.0
- 429 avec Retry-After et en-têtes RateLimitLivré · v0.1.0
Des comptes de plusieurs fournisseurs
- iss et aud vérifiés ; plusieurs émetteurs dans une même configurationLivré · v0.1.0
- Validation JWT, clés JWKS en cache avec rotationLivré · v0.1.0
Des événements publiés depuis HTTP
- Médiation de la frontière synchrone vers asynchroneLivré · v1.5.0
- Publication Kafka sous contrat, enveloppe CloudEventsLivré · v1.5.0
État dans la dernière version publiée de Flexway ; une fonctionnalité n'est marquée livrée qu'avec sa version.
Ce que Flexway ne fait pas
- Flexway relaie les flux, il ne les produit pas : la diffusion vidéo et l'encodage restent hors de son périmètre.
Parlons de votre passerelle
Flexwiz est une jeune entreprise : vous parlez directement avec la personne qui la fonde. Dites-nous ce que vous voulez faire passer par Flexway. Nous parlons de votre infrastructure et de vos exigences de souveraineté numérique.
La prise de rendez-vous en ligne arrive bientôt ; d'ici là, un e-mail suffit.