Facile à évoluer

Nous savons que les systèmes étroitement couplés sont des systèmes fragiles. Des micro-modules ou une structure basée sur des services sont utilisés même si c'est un monolithe. Le regroupement se fait par fonctionnalités/domaines, et non par couches techniques (Domain-Driven Design léger). Le frontend et le backend sont découplés via des contrats API (OpenAPI, GraphQL). Avantages : Facile à isoler, à mettre à l'échelle ou à remplacer des modules sans casser l'ensemble du système.

Nous choisissons des environnements d'exécution évolutifs (principalement Node.js) pour le backend. PostgreSQL, bases de données compatibles cloud PostgreSQL, Supabase, Firebase sont utilisés si nécessaire. Redis est intégré pour un trafic de lecture élevé ou pour le cache. Une infrastructure cloud-native et Docker sont utilisés : AWS / GCP / — avec support d'autoscaling. Les outils obscurs qui ne peuvent pas évoluer horizontalement ou qui manquent de soutien communautaire sont évités.

Nous savons que tout ne doit pas se faire en temps réel. Les tâches de longue durée ou en arrière-plan (emails, traitement d'images, facturation) sont déléguées à des files d'attente, etc. Exemple : Après qu'un utilisateur s'inscrit, la facturation/l'email est traité en arrière-plan, et non en ligne. Cela aide à améliorer les performances et l'évolutivité.

Nous savons qu'un mauvais schéma = retravail futur. Des API versionnées (/api/v1/...) sont utilisées pour éviter de casser les clients. Les UUID sont privilégiés par rapport aux ID incrémentaux (par exemple, pour fusionner des données à travers les régions). La multi-location est prévue (surtout dans le SaaS) : séparation au niveau des lignes vs séparation au niveau du schéma, ajouter tenant_id tôt.

Nous savons que vous ne pouvez pas évoluer ce que vous ne pouvez pas voir. Des outils comme Sentry sont utilisés pour le suivi des erreurs frontend ; Prometheus pour l'observabilité backend/infrastructure ; PostHog, Google Analytics pour l'analyse de produit ; Des vérifications continues pour la surveillance des temps d'arrêt. Des alertes (Slack/email) sont mises en place pour les pannes, les files d'attente en retard, les pics de DB, etc.

Nous savons que les monolithes peuvent évoluer, mais les services sans état évoluent mieux. Le stockage des sessions utilisateur en mémoire locale est évité — Redis/stores de session sont utilisés. Les serveurs sont rendus sans état afin qu'ils puissent être dupliqués facilement. La conteneurisation est utilisée : Docker + orchestrateurs (fournisseurs de cloud). Cela permet l'autoscaling sans sessions persistantes ou goulets d'étranglement de mémoire partagée.

Nous savons que plus d'utilisateurs = plus de surface d'attaque. Des modèles RBAC/ABAC (contrôle d'accès basé sur les rôles) sont mis en place. La limitation de débit, la validation des entrées et les en-têtes de sécurité sont appliqués. Les secrets sont conservés dans des coffres et tournés.

Couche API : La limitation de débit, la pagination, la fédération GraphQL (si nécessaire) sont mises en œuvre. Frontend : Le chargement paresseux, l'hébergement CDN, le découpage de code sont utilisés. L'autoscaling est utilisé. Base de données : Les index sont réindexés, le sharding est prévu si nécessaire, et ainsi de suite.