Une API en Rust sur trois serveurs
retour d'expérience

L'architecture, en trois rôles

Les trois serveurs sont joints par un réseau privé, et l'administration passe par un bastion : aucun port d'administration n'est ouvert publiquement.

Pourquoi Rust pour l'API

Le service doit rester debout sans surveillance. Un binaire unique, sans machine virtuelle à embarquer, démarre en quelques millisecondes et ne consomme presque rien au repos. La vérification des types attrape à la compilation une catégorie entière de bugs qui, ailleurs, n'apparaissent qu'en production.

Le coût est réel : la compilation est lente, la courbe d'apprentissage est raide, et le recrutement local sur ce langage est difficile. Nous l'avons accepté pour un service qui ne doit pas tomber, pas comme choix par défaut.

La chaîne d'intégration, du commit à la production

Chaque envoi déclenche trois étapes : tests, compilation, déploiement. Le pipeline affiche trois succès ou il bloque. Sur la mise en service, les mesures faites depuis l'extérieur donnaient une latence de l'ordre de dix-huit millisecondes sur la route de santé, avec une disponibilité continue depuis la mise en ligne.

Ce que nous referions autrement

• Écrire les tests avant le déploiement public la tentation d'ouvrir tôt pour montrer le service coûte toujours une semaine de dette.
• Figer les versions des images de base une mise à jour silencieuse de l'environnement a cassé une compilation un vendredi soir.
• Documenter la restauration, pas seulement la sauvegarde une sauvegarde jamais restaurée n'est pas une sauvegarde, c'est un fichier.

Le langage n'a jamais été le sujet. Ce qui a fait la différence, c'est l'isolement des rôles, l'automatisation du déploiement et des sauvegardes que l'on sait restaurer.