Un service Rust pour l'unique job lié au CPU

Le traitement d'images — redimensionner, générer des variantes de vignettes — est intensif en CPU, vraiment différent de caractère de la plupart de la charge d'un back-end, qui est majoritairement liée aux E/S, en attente d'une base ou d'une API externe. Le faire tourner dans le processus Node principal risque de bloquer la boucle d'événements mono-thread pour tout le reste à ce moment-là — une rafale de génération de vignettes qui dégrade les temps de réponse de l'API pour des requêtes complètement sans rapport, toutes en concurrence pour la même boucle d'événements.

Le sortir dans son propre service résout la contention de la boucle d'événements peu importe le langage. Rust en particulier apporte de vraies performances pour le travail lié au CPU — pas de pauses de ramasse-miettes, une vraie sûreté mémoire à la compilation sans la surcharge d'exécution qu'un langage interprété ou à GC paie pour les mêmes garanties. Pour une charge purement calculatoire sans besoin des bibliothèques de l'écosystème Node, le débit brut de Rust ici est un gain mesurable.

Ça étend la même idée que l'abstraction de stockage — découpler où vivent les fichiers du reste de l'application — à la façon dont les fichiers sont traités. Le rôle du back-end devient l'orchestration : recevoir l'upload, stocker l'original, déléguer une requête de traitement, pas faire le travail lourd en CPU en ligne.

Ça ne vient pas gratuitement

Un service séparé est un vrai coût opérationnel — une chose de plus à déployer et surveiller, un saut réseau de plus avec ses propres modes de défaillance, vraiment deux chaînes d'outils pour une personne. Réserve le découpage aux charges où le bénéfice de performance ou d'isolation est réel et mesurable, pas comme un instinct par défaut parce que ça a l'air plus propre sur le papier.

C'était un des ajouts plus tardifs d'une construction d'infrastructure réactive — Docker, puis Redis, puis pgBouncer, puis Caddy, puis Cloudflare, puis ça — ajouté une fois que le traitement de vignettes à l'échelle réelle est devenu un besoin concret et mesuré, pas conçu d'entrée dès le premier jour. Ce qui a marché, mais est venu avec un vrai remue-ménage évitable en chemin. (C'est aussi devenu plus tard son propre avertissement — le service a tourné en bonne santé pendant des mois alors que rien ne consommait sa sortie, parce que chaque résolveur d'URL du produit signait l'original en pleine résolution à la place.)