Aller au contenu principal
Capacité

Salle d'attente

Quand la foule est plus grande que l'application, la file doit se tenir devant — ordonnée, équitable, et avec un numéro que le visiteur voit réellement.

TR7 Waiting Room admet les visiteurs au rythme que votre application peut servir et retient les autres dans une file ordonnée sur la plateforme de delivery. Deux plafonds font le travail : combien de visiteurs peuvent être à l'intérieur en même temps, et à quelle vitesse de nouveaux peuvent entrer. Tout le reste — la page à votre marque, la position, le temps estimé, l'exemption des moteurs de recherche vérifiés — existe pour que la file soit quelque chose qu'on supporte plutôt que quelque chose qu'on quitte.

Par service
Chaque service publié a son propre plafond et sa propre page d'attente
0
Lignes de code applicatif modifiées pour placer une file devant
Observation
Mode qui dimensionne la file avant l'événement plutôt que pendant

Un jour de lancement ne tombe pas lentement. Il tombe d'un coup.

Le dimensionnement suppose que le trafic arrive à un certain rythme. L'ouverture des ventes, le lancement d'une campagne, la publication des résultats d'examen et l'ouverture des rendez-vous n'arrivent pas à un rythme — ils arrivent d'un seul instant. L'application ne se dégrade pas poliment : le pool de connexions se remplit, la base de données s'engorge, les temps de réponse montent et les utilisateurs rechargent, ce qui double la charge à l'origine du problème.

Les réponses habituelles aggravent la situation. L'autoscaling ajoute des instances après le pic et après que la base est déjà le goulot d'étranglement. La limitation de débit refuse des requêtes — ce qui, pour quelqu'un qui fait la queue pour un billet de concert, ne se distingue pas d'un site en panne. Les deux laissent la même impression : au moment où vous vouliez le plus être prêt, vous ne l'étiez pas.

Une salle d'attente change la forme du problème. La foule n'est ni refusée ni jetée : elle est ordonnée. L'application sert le nombre qu'elle sert bien, tous les autres gardent une place avec une position et une estimation, et la plateforme admet le suivant dès qu'une place se libère.

Notre approche

La file tourne sur la plateforme de delivery, devant l'application : elle tient donc debout quand l'application est déjà à sa limite — et aucun code applicatif n'intervient pour admettre, retenir ou libérer qui que ce soit.

Un plafond que l'application peut réellement servir

Définissez le nombre maximum de visiteurs autorisés simultanément dans un service publié. Ce nombre vient de ce que l'application encaisse bien de façon démontrée, pas de ce que le matériel pourrait théoriquement laisser passer.

Un portail sur la vitesse d'arrivée, pas seulement sur la taille de la foule

Un plafond distinct limite le nombre de nouveaux visiteurs par minute. C'est ce qui protège un backend qui supporte une grande population stable mais s'effondre quand dix mille personnes arrivent dans la même seconde.

Mode observation — la capacité se trouve avant l'événement

Faites tourner la salle d'attente en mode observation : elle compte ce qui se serait passé sans retenir personne. Vous dimensionnez la file sur votre propre trafic, un jour ordinaire, et vous arrivez à l'événement avec un chiffre auquel vous faites confiance.

Les bots vérifiés ne prennent pas de place dans la file

Les moteurs de recherche vérifiés et les sondes de supervision sont reconnus et exemptés : l'indexation et les contrôles de disponibilité continuent pendant l'événement et aucune place n'est dépensée pour du trafic qui n'allait rien acheter.

Capacités

Tout ce qui suit se configure par service publié, sur le même écran que le reste de la politique de trafic, et chaque changement prend effet par rechargement à chaud — y compris pendant l'événement.

Visiteurs simultanés maximum, par service publié

Chaque application a ses limites, et un même équipement peut faire tourner une salle d'attente différente pour chacune, en même temps. Le plafond est une propriété du service, pas du boîtier.

Nouveaux visiteurs par minute — protection contre les pics

Le portail d'arrivée est indépendant du plafond de concurrence. Un pool à l'aise avec 20 000 personnes à l'intérieur peut malgré tout être détruit par 20 000 arrivées d'un coup ; c'est ce réglage qui sépare les deux cas.

Pages d'attente conditionnelles — seulement là où c'est utile

La file s'applique par condition : les parcours de paiement et de billetterie sont protégés tandis que le catalogue, l'aide et la page de statut restent ouverts. Le visiteur attend pour ce qui est rare, pas pour tout le site.

Position et temps estimé, montrés au visiteur

Une file sans numéro ne se distingue pas d'un blocage. La page d'attente indique où se trouve le visiteur et combien de temps cela devrait prendre : c'est la différence entre attendre et partir.

La place est conservée — recharger ne la coûte pas

La position est liée à la session du visiteur : un rechargement, une coupure ou un passage de la 4G au Wi-Fi ne renvoie personne en fin de file. Les tempêtes de rechargement cessent d'être un mal auto-infligé.

Votre propre page d'attente

La page est un gabarit que vous contrôlez — votre marque, votre langue, votre message — servi par la plateforme même quand l'application derrière est totalement occupée.

Admis dès qu'une place se libère

À mesure que les sessions se terminent, les visiteurs suivants sont libérés automatiquement. Personne n'attend un minuteur qui ne correspond plus à la réalité.

Visibilité en direct pendant l'événement

Profondeur de file, admissions par minute, attente moyenne et taux d'abandon sont à l'écran pendant l'événement : la décision de relever ou d'abaisser le plafond se prend sur des faits.

Profondeur opérationnelle

Une salle d'attente ne vaut que par son comportement dans les cas gênants — un basculement en plein événement, une flotte de bots dans la file, un visiteur sur une connexion instable.

01

La file est sur la plateforme, pas dans l'application

Pas d'agent, pas de bibliothèque, pas de modification de code et pas de service de file à exploiter. L'application n'apprend jamais qu'une salle d'attente existe ; elle ne voit simplement jamais plus de trafic qu'elle ne peut servir.

02

Ordre équitable, lié à la session

L'admission se fait dans l'ordre d'arrivée, et la position suit la session du visiteur plutôt qu'une adresse IP : un NAT d'entreprise, un CGNAT d'opérateur ou une ligne de bureau partagée ne met pas tout le monde à la queue leu leu.

03

Se combine avec le reste de la protection

Le scoring de bots s'exécute avant la file : le trafic automatisé est traité plutôt que mis en attente. La limitation de débit continue de s'appliquer à ceux qui sont à l'intérieur. La salle d'attente gère la foule honnête ; on ne lui demande pas d'être un contrôle de sécurité.

04

Survit à un basculement

L'état de la file est répliqué dans le cluster : la panne d'un nœud pendant une ouverture de ventes ne réinitialise pas la file. L'événement continue sur le nœud restant, positions intactes.

05

Comportement au rechargement, aux nouveaux onglets et aux appareils partagés

Un second onglet rejoint la même place au lieu d'en prendre une seconde. Des règles explicites couvrent l'expiration de session et l'abandon : les places laissées par des visiteurs partis retournent dans la file.

06

Activable et désactivable pendant l'événement

Toute la fonction est un changement à chaud. Elle peut être activée quelques minutes avant l'ouverture des ventes et désactivée dès le pic passé, sans perdre une connexion ni rien redémarrer.

Quand l'utiliser

Ouvertures de billetterie

Concerts, matchs et ventes de voyages concentrent le trafic d'une année en quatre-vingt-dix secondes. La salle d'attente transforme un pic inservable en file ordonnée, et chaque visiteur garde une place qu'il voit.

Lancements de produits et campagnes

Une campagne qui marche est, au niveau réseau, indiscernable d'une attaque. La salle d'attente laisse le marketing réussir sans demander à l'infrastructure d'absorber tout ce succès en une seconde.

Fenêtres de dépôt dans le secteur public

Résultats d'examens, échéances fiscales et ouvertures de rendez-vous sont annoncés à toute une population à la minute près. Une file avec position visible est aussi la réponse la plus équitable qu'on puisse donner aux citoyens.

Pics de paie et de fin de mois en banque

Des pics prévisibles et répétés ne justifient pas de dimensionner en permanence pour la pire heure du mois. La salle d'attente couvre le pic, la plateforme reste dimensionnée pour le jour ordinaire.

Questions fréquentes

En quoi est-ce différent de la limitation de débit ?
La limitation de débit refuse les requêtes au-delà d'un seuil ; le visiteur reçoit une erreur et ne sait pas quoi faire. Une salle d'attente accepte tout le monde et l'ordonne — personne n'est refusé, chacun sait où il en est et combien de temps cela prendra à peu près. Les deux ont leur place et fonctionnent ensemble : la limitation traite l'abus, la salle d'attente traite une demande légitime simplement plus grande que l'application.
Faut-il modifier l'application ?
Non. La file tourne sur la plateforme de delivery devant l'application : aucune bibliothèque à intégrer, aucun agent à installer, aucun service de file à exploiter. L'application ne voit que le trafic déjà admis.
Comment choisir le bon nombre de visiteurs simultanés ?
Faites d'abord tourner la salle d'attente en mode observation. Elle compte, sur votre propre trafic, ce qui aurait été mis en file sans retenir personne : vous fixez le plafond sur les faits d'une semaine ordinaire plutôt que sur une estimation faite sous pression le jour J.
Que se passe-t-il si un visiteur recharge ou perd sa connexion ?
La place est liée à la session, pas à la requête : un rechargement, une coupure ou un changement de réseau conservent la position. C'est plus important qu'il n'y paraît — sinon les visiteurs inquiets rechargent, le rechargement multiplie la charge, et la file se met à causer le problème qu'elle devait empêcher.
Les moteurs de recherche et la supervision restent-ils bloqués dans la file ?
Non. Les moteurs vérifiés et les sondes de supervision sont reconnus et exemptés : indexation et contrôles de disponibilité se poursuivent normalement pendant l'événement, sans consommer de place.
Qu'advient-il de la file si un nœud du cluster tombe pendant l'événement ?
L'état de la file est répliqué dans le cluster : le nœud restant poursuit la même file, positions intactes. Un basculement en pleine ouverture de ventes ne devient pas un second incident.

Être prêt pour la minute qui décide du trimestre

Un plafond de concurrence, un portail d'arrivée et une file à votre marque — configurés par service, dimensionnés en mode observation avant l'événement. Mettons cela en place sur votre propre trafic.