Bulkhead

L'isolement par compartiment des sous-marins, appliqué aux pools de ressources : empêcher qu'une panne se propage.

Problème

Un hub EDI dialogue avec 200 partenaires via AS2, AS4, SFTP. Si tous partagent le même pool de 100 threads et 500 connexions HTTP, un seul partenaire malade (latence à 30s par requête) sature progressivement le pool et bloque les 199 autres. Résultat : un incident chez un fournisseur secondaire fait tomber les flux Walmart.

Forces

• Toutes les pannes ne sont pas binaires. Un partenaire lent (sans timeout) est pire qu'un partenaire down — il accapare des ressources actives.
• Les SLA partenaires diffèrent. Walmart impose 5s, un fournisseur 4ème rang accepte 30s — leurs flux ne doivent pas cohabiter dans le même pool.
• La sur-allocation gaspille. Donner 100% de la capacité à chaque partenaire est impossible — il faut un quota pondéré par volume métier.
• L'isolation a un coût d'observabilité. Plus de pools = plus de métriques = plus de dashboards.

Solution

Découper le hub en compartiments isolés : par partenaire critique (Walmart, Carrefour, Stellantis dédiés), par type de protocole (AS2 séparé d'AS4 et de SFTP), par criticité métier (commandes séparées des factures, séparées de la télémétrie). Chaque compartiment a son pool de threads, ses connexions, son quota de mémoire, son timer de timeout — paramétrés selon son SLA. Une saturation reste locale au compartiment.

┌──────────────┬──────────────┬──────────────┬──────────────┐
│  Walmart     │  Carrefour   │  Stellantis  │  BNP         │
│  thread-pool │  thread-pool │  thread-pool │  thread-pool │
│  20 threads  │  20 threads  │  20 threads  │  10 threads  │
│  100 conn AS2│  100 conn AS2│  50 conn AS4 │  20 conn SFTP│
└──────────────┴──────────────┴──────────────┴──────────────┘

Walmart en panne → ses 20 threads bloqués, mais les autres
partenaires continuent à 100% de capacité.

Implémentation EDI

Cas concret : dans Sterling B2B Integrator, on configure des « Mailbox Groups » par partenaire majeur, chacun avec sa pool de threads et son timeout. Sur Kubernetes, on déploie un Pod dédié Walmart, un autre Carrefour, scalés indépendamment. Sur Kafka, on crée un topic edi.in.walmart séparé de edi.in.carrefour, chacun consommé par un consumer group dédié. Sur l'API REST de l'API gateway, on applique un rate-limit par partner clé : si Walmart absorbe tout son quota, il n'affecte pas Carrefour.

Anti-patterns

• Pool global partagé. Une seule pool de threads pour tous les partenaires : une panne contamine l'ensemble.
• Compartiments sans timeout. Isolation parfaite, mais les threads d'un compartiment se bloquent pour toujours sur un partenaire mort.
• Trop de compartiments. Un compartiment par partenaire pour 5 000 partenaires : overhead opérationnel ingérable. Regrouper les partenaires non-critiques.
• Bulkhead sans observabilité. Sans métriques par compartiment, on ne sait pas qu'on est en saturation locale : l'isolation est invisible.

Patterns liés

• Circuit Breaker — souvent combiné, un par compartiment.
• Back-pressure — la régulation amont, complémentaire de l'isolation.
• Rate Limiter — typiquement appliqué par compartiment.

Sources

• Nygard M. — Release It! Design and Deploy Production-Ready Software, Pragmatic Bookshelf 2018 (2e éd.), chap. « Bulkheads ». La référence canonique du pattern.
• Microsoft Architecture Center — Bulkhead pattern. learn.microsoft.com — Bulkhead
• Netflix — Hystrix. Implémentation historique du Bulkhead + Circuit Breaker (déprécié, mais référence pédagogique). github.com/Netflix/Hystrix — Bulkhead
• Resilience4j — Bulkhead module. L'implémentation Java moderne du pattern. resilience4j.readme.io/docs/bulkhead