Dark Launch

La nouvelle version reçoit du trafic réel en parallèle de l'ancienne, mais ses résultats restent invisibles pour le partenaire. La validation sous charge réelle sans risque utilisateur — le pattern signature du refactoring graduel.

Problème

On souhaite valider une nouvelle implémentation (un nouveau parseur EDIFACT, un nouveau moteur de validation EN 16931) en conditions réelles, mais sans aucun risque que ses sorties divergent du comportement legacy attendu par les partenaires. Les tests synthétiques ne capturent pas toujours les cas réels. Un Canary expose même 1% du trafic au risque. On veut le réalisme de la production sans la conséquence.

Forces

• Le réalisme du trafic réel est nécessaire : seuls les vrais messages capturent toute la diversité.
• L'impact utilisateur doit être nul : la sortie de v2 ne doit jamais arriver chez le partenaire.
• La comparaison v1/v2 doit être quantifiée : taux de divergence, types d'écarts, performances.
• Le coût en ressources double pour les flux concernés : chaque message est traité deux fois.
• L'audit doit distinguer prod et shadow : les sorties shadow ne doivent pas polluer les archives fiscales.

Solution

Dupliquer le trafic entrant via un splitter ou un tee. Le pipeline v1 (legacy) traite normalement et renvoie la réponse au partenaire. Le pipeline v2 (dark) traite le même message en parallèle, sans renvoyer aucune réponse. Les sorties v2 sont persistées dans un stockage shadow, comparées aux sorties v1, et utilisées pour construire un dashboard de divergence. Une fois la confidence acquise (par exemple, < 0,01% de divergence sur 1 semaine), bascule en Canary puis 100%. Variante Github Scientist : une bibliothèque qui encapsule ce pattern au niveau code, mesure statistiquement la conformité.

Trafic dupliqué, sortie comparée :

       INVOIC entrant
            │
            ▼
   ┌────────────────┐
   │  Tee splitter  │  (copie le message)
   └─┬──────────┬───┘
     │          │
     ▼          ▼
  v1.0 prod   v2.0 dark
  (renvoie)   (calcule, persiste, ne renvoie pas)
     │          │
     ▼          ▼
  Réponse →  Stockage compare-shadow
  partenaire   • mêmes résultats ?
               • performances acceptables ?
               • erreurs ?
                       │
                       ▼
               Dashboard d'écart v1 vs v2
               Investigation des divergences

Implémentation EDI

Cas concret : refactoring d'un parseur EDIFACT INVOIC custom Java sur 10 ans de patchs, remplacé par un nouveau parseur basé sur Smooks. Sans Dark Launch : tests synthétiques validés mais incertitude sur les cas exotiques (caractères spéciaux, encodings rares, segments customs partenaires). Avec Dark Launch : chaque INVOIC entrant est traité par les deux parseurs. La sortie JSON canonique est comparée champ par champ. Sur 100k messages en 1 semaine, on observe : 99,98% identiques, 0,02% divergence (~20 messages). Investigation : 18 dûs à un comportement legacy non documenté (tolérance d'un délimiteur non-standard) que le nouveau parseur traite mieux. 2 dûs à un bug de Smooks à corriger. Après fix, divergence à 0%, bascule en Canary 1% → 100%. Outils : Github Scientist (Ruby, ports Python/Java disponibles), Apache Kafka MirrorMaker pour duplication asynchrone, custom tee dans le bus interne.

Anti-patterns

• Side effects en dark : si la v2 dark envoie réellement un MDN ou écrit dans une DB partagée, c'est plus du dark launch, c'est un déploiement caché — incidents en production.
• Comparaison naïve : si v1 et v2 produisent des résultats sémantiquement équivalents mais syntaxiquement différents (ordre de champs, espaces), la comparaison brute explose en divergence.
• Dark launch infini : rester en dark 6 mois double durablement les coûts pour aucun bénéfice incrémental au-delà des premières semaines.
• Pas de critère de promotion : passer en Canary « quand ça paraît bon » = pas mieux que sans dark launch.
• Latence ajoutée bloquante : si le splitter bloque l'appel v1 en attendant v2, la latence partenaire dérive — le dark doit être asynchrone et tolérant aux pannes.

Patterns liés

• Canary Release — étape suivante naturelle après dark launch validé.
• Feature Flag — pilote l'activation du dark launch.
• Wire Tap — pattern EIP voisin pour observer un canal sans le perturber.
• Detour — pattern EIP voisin pour activer une étape optionnelle.
• Blue-Green Deployment — pattern de bascule complémentaire après dark launch.

Sources

• Github Scientist : bibliothèque open-source de référence pour le dark launch au niveau code. Permet de tester une nouvelle implémentation en parallèle de l'ancienne et de mesurer la divergence. github.com/github/scientist
• Facebook Engineering — Building and testing at Facebook. Le terme « dark launch » a été popularisé par Facebook pour décrire le déploiement progressif d'une nouvelle fonctionnalité sans la rendre visible aux utilisateurs avant validation.
• Newman S. — Building Microservices, O'Reilly 2015 (2e éd. 2021). Chapitre sur le release et le shadow testing dans les systèmes distribués.
• Humble J., Farley D. — Continuous Delivery, Addison-Wesley 2010. Chapitre 10 sur les techniques de release avancées.
• Beyer B. et al. — Site Reliability Engineering, O'Reilly 2016. Chapitre 27 (Reliable Product Launches at Scale) sur les patterns de lancement progressif. sre.google/sre-book
• LinkedIn Engineering — Dark Launching : cas d'usage publics du pattern dans l'ingénierie LinkedIn pour tester de nouvelles fonctionnalités sous charge réelle.