Construire des plateformes SaaS évolutives : modèles d'architecture pour plus de 10 millions d'utilisateurs

Le défi de l'évolutivité

Construire une plateforme SaaS qui fonctionne pour 100 utilisateurs est trivial. En construire une qui fonctionne pour 10 millions — tout en maintenant des temps de réponse inférieurs à 100 ms, une disponibilité de 99,99 % et une équipe assez petite pour avancer vite — est l'un des problèmes les plus difficiles de l'ingénierie logicielle.

Ce guide documente les décisions architecturales et les modèles que les meilleures équipes d'ingénierie utilisent pour y parvenir.

La pyramide de l'évolutivité

Pensez à l'évolutivité comme une pyramide, construite de bas en haut :

1. Couche de données (conception de base de données, sharding, réplication)
2. Couche applicative (services sans état, mise en cache)
3. Couche infrastructure (équilibrage de charge, auto-scaling)
4. Couche réseau (CDN, edge computing)

Si vous vous trompez sur les couches inférieures, aucune quantité d'infrastructure ne vous sauvera.

Architecture de base de données

Modèles de multi-location (multi-tenancy)

Il existe trois approches courantes pour la conception de bases de données multi-tenant :

Pour la plupart des plateformes SaaS, nous recommandons de commencer avec une base de données partagée, des schémas séparés, puis de migrer les principaux clients entreprise vers des bases de données dédiées à mesure qu'ils grandissent.

Répliques de lecture et CQRS

// Modèle CQRS : séparer les modèles de lecture et d'écriture
class OrderCommandService {
  async createOrder(data: CreateOrderDTO) {
    const order = await this.db.write.orders.create(data);
    await this.eventBus.publish('order.created', order);
    return order;
  }
}

class OrderQueryService {
  async getOrderHistory(userId: string) {
    // Lecture depuis la réplique — pas de verrous d'écriture !
    return this.db.readReplica.orders.findMany({
      where: { userId },
      include: { items: true, payments: true },
    });
  }
}

Architecture événementielle

L'arme secrète des plateformes SaaS évolutives est l'architecture événementielle. Plutôt que les services s'appellent directement entre eux, ils communiquent via des événements.

Avantages

• Découplage : les services n'ont pas besoin de se connaître mutuellement
• Résilience : si un service est en panne, les événements sont mis en file d'attente et traités à sa reprise
• Évolutivité : chaque service peut évoluer indépendamment selon sa charge

Implémentation avec Kafka

// Producteur — lorsqu'une commande est créée
await kafka.send({
  topic: 'order-events',
  messages: [{
    key: order.id,
    value: JSON.stringify({
      type: 'ORDER_CREATED',
      payload: order,
      timestamp: new Date().toISOString(),
    }),
  }],
});

// Consommateur — service de facturation
kafka.run({
  eachMessage: async ({ message }) => {
    const event = JSON.parse(message.value!.toString());
    if (event.type === 'ORDER_CREATED') {
      await billingService.processPayment(event.payload);
    }
  },
});

Stratégie de mise en cache

Les trois niveaux de cache dans un SaaS moderne :

1. Cache navigateur : assets statiques, réponses API avec en-têtes de cache
2. Cache CDN : contenu distribué géographiquement
3. Cache applicatif : Redis pour les données de session, résultats calculés et requêtes de base de données fréquentes

Règle empirique : si une requête s'exécute plus d'une fois par seconde et que son résultat change moins d'une fois par minute, elle devrait être mise en cache.

Déploiements sans interruption

Les temps d'arrêt sont inacceptables pour les plateformes SaaS. Réaliser des déploiements sans interruption nécessite :

1. Déploiements blue-green : exploiter deux environnements de production identiques
2. Feature flags : déployer du code sans activer les fonctionnalités
3. Stratégies de migration de base de données : modèle d'expansion/contraction pour les changements de schéma
4. Health checks : basculement automatique du trafic selon l'état de santé du service

Les plateformes qui gagnent sont celles capables de livrer sans crainte — déployer 10 fois par jour sans briser la confiance de leurs utilisateurs.