Le temps de disponibilité n'est pas une mesure de marketing pour nous. C'est une contrainte d'ingénierie qui façonne chaque décision que nous prenons. Lorsque l'ensemble de votre entreprise opère sur une plate-forme unique, le temps d'arrêt n'est pas un inconvénient. C'est un arrêt complet. Cette responsabilité est quelque chose que nous prenons au sérieux, et elle se reflète dans chaque couche de l'architecture KamoCRM, de la base de données à l'équilibreur de charge.

À la fondation, nous gérons YugabyteDB comme notre principale boutique de données. YugabyteDB est une base de données SQL distribuée qui réplique des données à travers plusieurs nœuds avec un basculement automatique. Si un noeud tombe en panne, le cluster continue à fonctionner sans perte de données ni intervention manuelle. En plus de cela, notre couche d'application consiste en plus de 64 microservices apatrides fonctionnant sous Kubernetes via RKE2. Chaque service étant apatride, tout cas peut être remplacé ou mis à l'échelle sans affecter les autres.

La communication en temps réel ajoute une autre couche de complexité. La visioconférence, la messagerie et les appels téléphoniques nécessitent tous des connexions persistantes et une faible latence. Nous nous en oignons avec Janus WebRTC pour les médias et NATS JetStream pour le courtage de messages, tous deux déployés dans des configurations très disponibles à travers notre cluster. Même notre couche de stockage de fichiers, alimentée par MinIO, est configurée avec un codage d'effacement pour la durabilité des données.

Il en résulte un système sans composante unique dont la défaillance enlève le reste. Actualise le navire plusieurs fois par jour en tant que déploiements de roulage, de sorte que la libération ne coûte pas de disponibilité. Des milliers de paramètres sont suivis en direct, et le mécanicien de garde entend parler d'une anomalie en quelques secondes. C'est ce qui se trouve derrière le chiffre de 99,9%.