Le Vrai Problème
Quand nous avons regardé cette plateforme de services financiers pour la première fois, elle avait cette odeur familière. Un monolithe servant 50 000 utilisateurs quotidiens, des déploiements nécessitant des fenêtres de maintenance nocturnes, et une codebase où toucher le module A cassait mystérieusement le module Z.
Le business voulait des coûts d'infrastructure plus bas, plus de flexibilité de développement, un time-to-market plus rapide, et la capacité de scaler des features individuelles indépendamment. Classique - mais le diable est dans les détails.
Microservices : Hype vs Réalité
Soyons honnêtes - les microservices résolvent des problèmes spécifiques, pas tous les problèmes. Voici ce qui a vraiment guidé notre décision :
- Indépendance de déploiement - livrer le module de paiement sans toucher à l'auth utilisateur
- Containment du blast radius - quand (pas si) les choses cassent, elles cassent petit
- Persistance polyglotte - utiliser Postgres pour les transactions, Redis pour les sessions, MongoDB pour les documents
- Ownership d'équipe - des limites claires signifient une responsabilité claire
- Scaling ciblé - scaler le service de recherche pendant les pics, pas toute l'app
Deep Dive Architecture
Nous avons construit sur le Domain-Driven Design, mais pas la version académique. Les bounded contexts ont émergé de vraies conversations d'équipe, pas d'exercices sur tableau blanc. Nos principes :
- Les limites d'agrégat définissent les limites de service - si c'est une transaction, c'est un service
- Events plutôt que calls synchrones - la chorégraphie bat l'orchestration dans la plupart des cas
- Contrats API comme citoyens de première classe - casse le contrat, casse le build
- Architecture shared-nothing - chaque service possède ses données, point
- L'observabilité n'est pas optionnelle - si tu ne peux pas le tracer, ne le ship pas
La Stack (Et Pourquoi)
Chaque choix d'outil était un tradeoff. Voici où nous avons atterri :
Infrastructure:
├── Kubernetes (EKS) → Déploiements déclaratifs, self-healing
├── Istio service mesh → mTLS, traffic shaping, circuit breaking
├── Kong API Gateway → Rate limiting, auth, transformation de requêtes
│
Messaging:
├── Kafka → Event backbone, rétention 7 jours
├── Redis Streams → Pub/sub léger, données éphémères
│
Data Layer:
├── PostgreSQL → Transactions ACID, JSONB pour flexibilité
├── MongoDB → Document store pour audit logs, activity feeds
├── Redis Cluster → Session store, caching distribué
├── Elasticsearch → Recherche full-text, agrégation de logs
│
Observability:
├── OpenTelemetry → Instrumentation vendor-agnostique
├── Prometheus + Thanos → Métriques avec stockage long terme
├── Grafana → Dashboards, alerting
├── Jaeger → Distributed tracing
│
CI/CD:
├── GitLab CI → Build, test, security scanning
├── ArgoCD → GitOps deployments
├── Sealed Secrets → Gestion de secrets native K8sPatterns Qui Nous Ont Sauvés
La théorie c'est bien. Voici ce qui nous a vraiment gardés hors des problèmes :
**Transactional Outbox** - Au lieu de dual-writes (base de données + message broker), nous écrivons les events dans une table outbox dans la même transaction. Un processus séparé les publie. Atomique. Fiable. Pas de cauchemars de transactions distribuées.
**Event Sourcing (là où ça compte)** - Pour les flux de paiement et les chemins critiques d'audit, nous stockons des events, pas de l'état. Chaque mutation est un event immuable. Debugger les problèmes de production en rejouant des séquences exactes. Les équipes compliance adorent.
**CQRS avec Projections** - Modèles d'écriture optimisés pour la validation, modèles de lecture optimisés pour les queries. L'eventual consistency est ok pour les vues de lecture. L'équipe reporting obtient ses tables dénormalisées sans polluer le write path.
**Saga Orchestration** - Processus métier de longue durée (onboarding, settlement de paiements) comme machines à états explicites. Transactions compensatoires en cas d'échec. Pas d'états partiels orphelins.
**Circuit Breaker + Bulkhead** - Hystrix est mort, mais les patterns non. Resilience4j gère circuit breaking, rate limiting et retry avec backoff. Thread pools séparés pour les intégrations externes.
Le Flux de Paiement : Architecture Réelle
Voici comment l'argent réel circule dans le système :
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ API Gateway │──────│ Payment │──────│ Fraud │
│ (Kong) │ gRPC │ Service │ Event│ Detection │
└─────────────┘ └──────┬──────┘ └──────┬──────┘
│ │
PaymentInitiated FraudCheckCompleted
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Outbox │ │ Risk │
│ Table │ │ Scoring │
└──────┬──────┘ └──────┬──────┘
│ │
Debezium CDC RiskAssessed
│ │
▼ ▼
┌─────────────────────────────────┐
│ Kafka Topics │
│ payments.initiated │
│ fraud.checked │
│ risk.assessed │
│ payments.completed │
└─────────────────────────────────┘
│
┌───────────────────────┼───────────────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Ledger │ │ Order │ │Notification │
│ Service │ │ Service │ │ Service │
└─────────────┘ └─────────────┘ └─────────────┘Stratégie de Test Qui Fonctionne Vraiment
Oublie la pyramide de tests pour un moment. Dans les systèmes distribués, tu as besoin de :
- Contract tests (Pact) - Les services parlent à des stubs, pas aux vraies dépendances. Les contrats cassent en CI, pas en production
- Consumer-driven contracts - Les consumers définissent ce dont ils ont besoin, les providers prouvent qu'ils livrent
- Chaos testing (Chaos Monkey, Litmus) - Tuer des pods aléatoirement. Injecter de la latence. Prouver la résilience
- Synthetic monitoring - Sondes de production continues pour les parcours utilisateur critiques
- Load testing comme validation - Nous avons validé que l'architecture pouvait gérer 80x le trafic original via des load tests rigoureux avant le lancement
- Canary deployments - 1% du trafic vers les nouvelles versions, rollback automatique en cas de pic d'erreurs
Ce Qui S'Est Vraiment Passé
Au début, nous nous sommes concentrés sur la décomposition du monolithe - identifier les coutures, étrangler l'ancien système service par service. Au départ, c'était difficile. Les compétences de debugging distribué manquaient, les traces étaient incomplètes, et les partitions réseau exposaient des bugs de consistance.
Après quelques mois, ça a cliqué. Les équipes possédaient leurs services end-to-end. Les déploiements sont devenus des non-événements. L'équipe platform engineering avait construit assez de golden paths pour que monter un nouveau service prenne des heures, pas des semaines.
Quand le temps a passé et que l'architecture a mûri, les résultats ont parlé d'eux-mêmes :
- Les temps de réponse sont passés de 850ms p99 à moins de 120ms p99
- Zero-downtime deployments - les fenêtres de maintenance sont devenues un souvenir
- Coûts d'infrastructure réduits de 35% malgré un trafic plus élevé
- Fréquence de déploiement : de mensuel à 50+ deploys quotidiens
- Temps moyen de récupération : moins de 5 minutes pour la plupart des incidents
Les Leçons Difficiles
Tout n'a pas été fluide. Voici ce qui a fait mal :
**L'eventual consistency est une feature, pas un bug** - Mais explique ça au PM qui se demande pourquoi le dashboard montre des données obsolètes. Conçois pour ça. Communique-le.
**Distributed tracing ou la mort** - Sans correlation IDs et propagation correcte du trace context, debugger c'est de l'archéologie. L'auto-instrumentation OpenTelemetry est ton ami.
**L'évolution de schéma est difficile** - Avro avec schema registry. Uniquement des changements backwards-compatible. Les breaking changes nécessitent un nouveau topic.
**Kubernetes est un système d'exploitation** - Ne te bats pas contre. Apprends-le. Resource limits, liveness probes, pod disruption budgets - ils existent pour des raisons.
**L'équipe plateforme n'est pas négociable** - Quelqu'un doit posséder les abstractions d'infrastructure. Sinon, chaque équipe réinvente la roue.
Quand NE PAS faire de Microservices
Parlons franchement - les microservices sont chers. Considère des alternatives si :
- Ton équipe est petite - l'overhead de coordination tuera la vélocité
- Les limites du domaine ne sont pas claires - tu les traceras mal et souffriras de douleurs de migration
- Tu n'as pas de capacité platform engineering - la complexité d'infrastructure explose
- Les exigences de latence sont extrêmes - les sauts réseau s'additionnent
- Ton monolithe a juste besoin d'une meilleure modularisation - essaie d'abord un monolithe modulaire
Points Clés
À la fin de ce voyage, nous avions une plateforme qui déployait en continu, scalait à la demande, et donnait aux équipes une vraie ownership. Le business a obtenu ce qu'il demandait : des coûts plus bas, une livraison plus rapide, et la flexibilité d'évoluer.
Est-ce que ça valait le coup ? Pour cette échelle et ces exigences, absolument. Mais nous avons commencé avec un monolithe modulaire et n'avons extrait des services que quand la douleur était réelle.
Tu penses à ce genre de transformation ? Commence par le problème, pas la solution.
Key Takeaways
L'architecture microservices ne consiste pas à suivre les tendances - il s'agit de résoudre des défis spécifiques de scaling et d'organisation. Les patterns que nous avons couverts (transactional outbox, event sourcing, CQRS, saga orchestration) ne sont pas des exercices théoriques ; ce sont des solutions éprouvées au combat pour de vrais problèmes de systèmes distribués.
Nous avons validé que l'architecture pouvait soutenir 80x le trafic original via du load testing complet. Les déploiements sont passés d'événements mensuels à des non-événements se produisant des dizaines de fois par jour. C'est le retour sur investissement quand tu fais bien les fondamentaux.
Tu as des défis d'architecture avec lesquels tu te débats ? Parlons patterns.
Engineering Team
Senior Solutions Architects
Nous construisons des systèmes distribués depuis avant que 'microservices' ne soit un terme. Nos cicatrices racontent des histoires.