Le marketing vous annonce qu'une campagne va générer dix fois le trafic normal mardi prochain. Que faites-vous ?

Faites des tests de charge contre le vrai goulot d'étranglement plutôt que contre l'étage web. Dérivez la capacité par composant du trafic actuel et de la marge disponible, puis examinez ce qui ne scale pas horizontalement : le débit d'écriture de la base, les limites de connexions, les limites de débit des tiers, et les quotas cloud. Pré-scalez au lieu de compter sur l'autoscaling pour réagir à temps, relevez les quotas à l'avance, préparez un plan de délestage et de dégradation, et staffez l'astreinte pour la fenêtre.

D'abord je préciserais ce que veut dire dix fois, parce que dix fois sur une journée est un problème différent de dix fois dans les quatre premières minutes d'un envoi d'e-mails, et les campagnes sont presque toujours le second cas. Ensuite je modélise chaque étage à partir de l'usage actuel : si on tourne à 30% de CPU en pointe aujourd'hui, l'étage sans état est facile, mais les parties intéressantes sont celles qui ne scalent pas en ajoutant des pods. Chez nous, c'était le débit d'écriture Postgres et un prestataire de paiement dont on n'avait jamais approché la limite de débit, ce qui a demandé un coup de téléphone et une semaine de délai. Je lancerais un test de charge qui frappe le vrai chemin, pas un health check synthétique, et je pré-scalerais plutôt que de m'en remettre à l'autoscaler, parce qu'un démarrage à froid de quatre-vingt-dix secondes est une éternité dans un pic. Enfin, un plan de dégradation écrit : ce qu'on coupe en premier, qui peut le basculer, et un canal partagé avec le marketing pour pouvoir mettre l'envoi en pause.