Microservices et données : patterns réalistes pour des équipes web
Bounded contexts, cohérence des données, sagas, idempotence, API gateway et observabilité ; liens concrets avec Node.js / Next.js (BFF) et compromis face au monolithe modulaire.
Les microservices découpent une application en services déployables indépendamment, chacun aligné sur une capacité métier ou technique cohérente. L'alternative la plus fréquente reste le monolithe modulaire : un seul dépôt et un seul processus, mais avec des frontières de code nettes. Le choix ne relève pas de la mode : il trade complexité réseau, cohérence transactionnelle et vélocité d'équipe.
Ce texte se concentre sur la gestion des données en architecture décomposée : comment éviter qu'un « tour de Babel » de bases ne rende les rapports impossibles, et quels patterns éprouvés aident à garder des invariants métier.
DDD et bounded contexts
Le Domain-Driven Design propose de modéliser le logiciel à partir du langage métier (ubiquitous language) et de délimiter des bounded contexts : une zone où un terme (ex. « Commande ») a une signification stable. Un microservice idéal recouvre souvent un contexte : le service « facturation » ne partage pas sa table SQL avec le service « catalogue ».
Base de données par service
Chaque service possède son schéma ou sa base : cela évite le couplage caché via migrations globales, mais impose des transactions distribuées explicites quand une opération touche plusieurs agrégats. On préfère souvent la saga : une séquence d'étapes locales avec des actions de compensation (annuler la réservation de stock si le paiement échoue).
Communication, API Gateway, événements
Les appels synchrones HTTP/gRPC restent simples à raisonner mais créent des chaînes de latence (A appelle B qui appelle C). Un API Gateway centralise l'authentification, le routage et parfois l'agrégation de réponses pour le front. Les architectures orientées événements publient des faits (« PaiementAccepté ») sur une file (Kafka, RabbitMQ, NATS) : plusieurs services réagissent sans se connaître directement, au prix d'une cohérence eventually consistent.
Le pattern circuit breaker (resilience4j, opossum côté Node) coupe temporairement les appels vers un voisin en panne pour préserver la capacité du système et éviter les cascades de timeouts.
Idempotence et double livraison
Les réseaux réessayent. Un même message peut arriver deux fois. Les handlers doivent être idempotents : un second traitement avec la même clé d'idempotence ne change pas l'état final (clé stockée en base, contrainte d'unicité sur un identifiant externe, etc.). C'est indispensable pour les webhooks de paiement ou les consumers de file.
CQRS et modèles de lecture
Le pattern CQRS (Command Query Responsibility Segregation) sépare les chemins d'écriture (commandes validant des invariants métier stricts) des chemins de lecture optimisés pour l'agrégation (vues matérialisées, search index, cache). Dans les microservices, il permet d'éviter des jointures SQL impossibles entre bases hétérogènes : un service « reporting » consomme des événements pour tenir à jour une projection dénormalisée.
La migration progressive (strangler fig pattern) enveloppe un monolithe existant derrière une façade qui route tranche par tranche le trafic vers de nouveaux services. Côté données, on duplique temporairement certaines lectures ou on synchronise via événements jusqu'à ce que l'ancienne voie puisse être retirée sans big bang risqué.
Observabilité et lien avec Next.js
La observabilité regroupe logs structurés (JSON avec correlation-id), métriques (latence p95, taux d'erreur par route) et traces distribuées (OpenTelemetry → Jaeger/Zipkin). Sans ces trois piliers, diagnostiquer une lenteur transverse à six services devient du devinage.
Dans une stack JavaScript, un Backend-for-Frontend (BFF) Next.js peut orchestrer plusieurs microservices pour composer une page : il adapte le contrat aux besoins précis du client (mobile vs web), mutualise l'authentification et limite le chattyness du navigateur. Attention au placement : trop de logique métier dans le BFF le transforme en monolithe distribué ambulant.
Logs
Centraliser (ELK, Loki) avec champs service, traceId, user anonymisé.
Métriques
Prometheus + Grafana ; RED method (rate, errors, duration).
Traces
OpenTelemetry SDK Node ; propager le contexte W3C traceparent.
En pratique — avant de multiplier les services
- ☐ Les frontières de domaine sont-elles stables ou encore fluides ? Si fluides, un monolithe modulaire peut aller plus vite.
- ☐ Avez-vous défini les sagas / compensations pour les workflows multi-services ?
- ☐ Chaque endpoint critique a-t-il budgets de latence, timeouts et idempotency keys ?
- ☐ Les équipes peuvent-elles déployer sans coordination permanente (ownership clair) ?
- ☐ Le plan d'observabilité est-il en place avant la première panne nocturne ?
Conclusion
Les microservices excellent quand les équipes, les domaines et l'exploitation sont matures. La gestion des données y est plus exigeante qu'en monolithe : cohérence explicite, messages fiables, observabilité de bout en bout. Pour un profil orienté Next.js et services Node, comprendre ces compromis permet de choisir consciemment entre découpage réseau et simplicité opérationnelle.