Design patterns d'intégration : ce qu'ils sont et lesquels reviennent souvent en entretien

Ce qu'ils sont et ce qu'ils ne sont pas

Un design pattern d'intégration est une solution réutilisable à un problème de communication entre systèmes distincts : des applications différentes, avec leurs propres réseaux, pannes, formats et temps de réponse. Ne le confondez pas avec deux autres familles :

• Patterns GoF (Gamma, Helm, Johnson, Vlissides, 1994, 23 patterns) : ils organisent les classes et les objets au sein d'un même processus. Exemples : Strategy, Factory, Decorator. Observer ressemble à Publish-Subscribe, mais il fonctionne en mémoire, dans une seule application, sans réseau, sans persistance et sans panne partielle.
• Patterns web (comme les patterns de présentation de Patterns of Enterprise Application Architecture, Fowler, 2002) : ils structurent la couche qui traite les requêtes HTTP d'une application. Exemples : MVC, Front Controller, Page Controller, Template View.
• Patterns d'intégration : ils traitent de ce qui se passe entre les applications. Comment livrer un message sans le perdre, comment le router, comment éviter que la panne d'un service entraîne les autres, comment garder la cohérence sans transaction distribuée.

En résumé, par échelle : le GoF vit dans le code, le web vit dans la requête, l'intégration vit entre les systèmes.

Références principales

1. Hohpe, G. ; Woolf, B. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, 2003. Un catalogue de 65 patterns, centré sur la messagerie et indépendant de la technologie.
2. Richardson, C. Microservices Patterns. Manning, 2018. Patterns d'architecture de microservices, dont les données distribuées et la résilience. La liste ci-dessous provient du pattern language de microservices.io (53 patterns), qui continue d'évoluer et peut contenir des éléments postérieurs au livre de 2018.

Quatre patterns qui reviennent souvent en entretien

Publish-Subscribe Channel

(Hohpe et Woolf, Enterprise Integration Patterns)

Le producteur publie un événement et tous les abonnés en reçoivent une copie, sans qu'il sache qui ils sont. Le service de commandes publie CommandeCréée, et le stock, la facturation et les notifications réagissent de façon indépendante.

Questions typiques : la différence avec Point-to-Point, ce qui arrive à un abonné hors ligne (Durable Subscriber) et comment gérer les doublons.

Circuit Breaker

(Richardson, Microservices Patterns)

Un proxy compte les échecs d'un service distant. Au-delà d'un seuil, le circuit s'ouvre et les appels échouent immédiatement, au lieu d'épuiser les threads dans des timeouts. Après un délai, il laisse passer quelques appels de test (semi-ouvert) et se referme s'ils réussissent. Cela évite les défaillances en cascade.

Questions typiques : les trois états, la différence avec retry et timeout, et quel fallback utiliser.

Saga

(Richardson, Microservices Patterns)

Elle remplace la transaction distribuée par une séquence de transactions locales, avec des transactions compensatoires quand une étape échoue. Créer la commande → réserver le stock → encaisser ; si l'encaissement échoue, on libère le stock et on annule la commande. Elle peut être chorégraphiée (les services réagissent aux événements) ou orchestrée (un coordinateur pilote les étapes). Le coût est la cohérence à terme.

Questions typiques : chorégraphie vs orchestration, et pourquoi ne pas utiliser le 2PC.

Transactional Outbox

(Richardson, Microservices Patterns)

Il résout le problème du dual write : enregistrer en base et publier sur le broker sans qu'un seul des deux n'aboutisse. Le message est écrit dans une table outbox dans la même transaction locale que la donnée métier, puis un relais le publie, par polling (Polling Publisher) ou en lisant le journal de la base (Transaction Log Tailing, comme Debezium). La livraison est at-least-once, donc le consommateur doit être idempotent.

Questions typiques : pourquoi ne pas publier juste après le commit, et comment éviter les doublons.

Ces quatre patterns sont une sélection fondée sur l'expérience du marché, pas un classement sourcé.

Liste : Enterprise Integration Patterns (65)

Source : Hohpe, G. ; Woolf, B. Enterprise Integration Patterns. Addison-Wesley, 2003.

• Styles d'intégration : File Transfer, Shared Database, Remote Procedure Invocation, Messaging
• Systèmes de messagerie : Message Channel, Message, Pipes and Filters, Message Router, Message Translator, Message Endpoint
• Canaux : Point-to-Point Channel, Publish-Subscribe Channel, Datatype Channel, Invalid Message Channel, Dead Letter Channel, Guaranteed Delivery, Channel Adapter, Messaging Bridge, Message Bus
• Construction des messages : Command Message, Document Message, Event Message, Request-Reply, Return Address, Correlation Identifier, Message Sequence, Message Expiration, Format Indicator
• Routage : Content-Based Router, Message Filter, Dynamic Router, Recipient List, Splitter, Aggregator, Resequencer, Composed Message Processor, Scatter-Gather, Routing Slip, Process Manager, Message Broker
• Transformation : Envelope Wrapper, Content Enricher, Content Filter, Claim Check, Normalizer, Canonical Data Model
• Endpoints : Messaging Gateway, Messaging Mapper, Transactional Client, Polling Consumer, Event-Driven Consumer, Competing Consumers, Message Dispatcher, Selective Consumer, Durable Subscriber, Idempotent Receiver, Service Activator
• Gestion du système : Control Bus, Detour, Wire Tap, Message History, Message Store, Smart Proxy, Test Message, Channel Purger

Liste : Microservices Patterns (53)

Source : Richardson, C. Microservices Patterns. Manning, 2018, d'après le pattern language de microservices.io (qui peut inclure des éléments postérieurs au livre).

• Style architectural : Monolithic Architecture, Microservice Architecture
• Frontières des services : Decompose by Business Capability, Decompose by Subdomain, Self-contained Service, Service per Team
• Refactorisation : Strangler Application, Anti-corruption Layer
• Collaboration entre services : Database per Service, Shared Database, Saga, Command-side Replica, API Composition, CQRS, Domain Event, Event Sourcing
• Messagerie transactionnelle : Transactional Outbox, Transaction Log Tailing, Polling Publisher
• Tests : Consumer-driven Contract Test, Consumer-side Contract Test, Service Component Test
• Déploiement : Multiple Service Instances per Host, Service Instance per Host, Service Instance per VM, Service Instance per Container, Serverless Deployment, Service Deployment Platform
• Préoccupations transverses : Microservice Chassis, Externalized Configuration, Service Template
• Communication : Remote Procedure Invocation, Messaging, Domain-specific Protocol, Idempotent Consumer
• API externe : API Gateway, Backend for Front-end
• Découverte de services : Client-side Discovery, Server-side Discovery, Service Registry, Self Registration, 3rd Party Registration
• Fiabilité : Circuit Breaker
• Sécurité : Access Token
• Observabilité : Log Aggregation, Application Metrics, Audit Logging, Distributed Tracing, Exception Tracking, Health Check API, Log Deployments and Changes
• UI : Server-side Page Fragment Composition, Client-side UI Composition