Plateforme E-commerce Multi-tenant

Contexte

Conception et déploiement d’une plateforme e-commerce multi-tenant, avec des exigences strictes en sécurité, isolation des données, performance et scalabilité. La plateforme permet à des marchands de créer et gérer des boutiques en ligne de manière autonome.

J’ai assuré la conception architecturale complète (backend, frontend, infrastructure), le déploiement en production, et j’ai supervisé l’équipe de développement.

Architecture logicielle

Modular Monolith

L’architecture choisie est un monolithe modulaire : un compromis pragmatique entre le monolithe classique et les microservices. Chaque module métier (authentification, catalogue, commandes, paiements, livraison, notifications…) est autonome dans sa structure interne tout en partageant un seul déploiement.

Pourquoi ce choix :

• Déploiement simple avec la clarté organisationnelle des microservices
• Chaque module peut être extrait en service indépendant si les besoins de scaling l’exigent
• Développement parallèle sans conflits entre développeurs

Domain-Driven Design (DDD)

Chaque module suit une Clean Architecture en 4 couches : Handler, Service, Repository, Domain.

• Entités et Value Objects alignés sur le vocabulaire métier, le code parle le même langage que les parties prenantes
• Invariants métier protégés dans le domaine, les règles de transition d’état (ex : une commande ne peut pas passer de “en attente” à “livrée” sans les étapes intermédiaires) sont garanties par le code, pas par des vérifications ad hoc
• Repository Pattern avec isolation systématique par tenant
• Logique métier testable indépendamment du framework HTTP et de la base de données

Event-Driven Architecture

Un bus d’événements interne découple les modules entre eux :

• Quand une commande est créée, le module de notification envoie un email, le module analytics met à jour les statistiques, sans que le module commande ne les connaisse
• Ajouter un nouveau comportement se fait en ajoutant un abonné, sans toucher au code existant (Open/Closed Principle)
• Les handlers sont asynchrones : si l’envoi d’un email échoue, la commande est quand même créée

Stack technique

Multi-tenancy

L’isolation entre tenants repose sur une stratégie Shared Database / Shared Schema avec plusieurs couches de protection :

• Filtrage systématique par identifiant de tenant sur chaque requête
• Middleware d’extraction et de validation du contexte tenant
• RBAC avec support de domaines pour des permissions granulaires par boutique (owner, manager, staff)

DevOps et Infrastructure

Conteneurisation

Chaque composant (API, Worker, Frontends) dispose d’un Dockerfile multi-stage optimisé : builds statiques, exécution en utilisateur non-root, health checks intégrés.

CI/CD avec GitLab

Pipeline GitLab CI/CD couvrant :

• Build : compilation et construction des images Docker
• Tests : tests unitaires avec détection de data races, couverture de code
• Lint : analyse statique
• Deploy : déploiement automatisé vers staging et production
• Migrations : exécution automatique des migrations de base de données

Monitoring et Observabilité

Stack de monitoring couvrant les 4 piliers de l’observabilité :

• Métriques : VictoriaMetrics + Grafana, dashboards de suivi des performances applicatives et infrastructure
• Alerting : VMAlert, alertes sur seuils critiques (latence, taux d’erreur, saturation)
• Logs : Loki + Grafana, agrégation centralisée et corrélation avec les métriques
• Error tracking : Sentry, capture des exceptions et traces de performance
• Sécurité : Wazuh (HIDS) + Suricata (IDS/IPS), détection d’intrusion host et réseau

Compétences mobilisées

• Architecture logicielle : DDD, Clean Architecture, Modular Monolith, Event-Driven
• Backend : Go, API REST, bases relationnelles, caching, job queues
• Frontend : React/Next.js, SSR, design system, SEO technique
• Sécurité : authentification JWT, RBAC, chiffrement, rate limiting, audit trail
• DevOps : Docker, CI/CD GitLab, monitoring, IDS/IPS
• Leadership : conception, supervision d’équipe, revue de code