Dark Launch

Le Dark Launch est une technique de déploiement où une nouvelle fonctionnalité est mise en production mais reste invisible aux utilisateurs finaux — soit cachée derrière un feature flag désactivé, soit exécutée en shadow mode (résultats non utilisés). Permet de valider performance, comportement et impact systémique de la feature en conditions réelles avant son release officiel.

Deux patterns principaux : (1) Hidden Launch (UI-level) — code feature déployé, UI masquée par feature flag OFF par défaut, gradually activée pour cohorts (employees → beta users → all) ; (2) Shadow Launch (backend-level) — duplique traffic production vers nouveau service/codepath en parallèle de l'existant, compare résultats sans servir les outputs aux users, mesure performance/correctness.

Use cases Hidden Launch : (1) nouvelle UI refactor — déployer, dogfood en interne, gradual rollout sans risquer break user experience ; (2) nouveau workflow checkout — feature flag, test internal users d'abord ; (3) major redesign — déploiement progressif basé feedback ; (4) new payment method — ramp up gradually.

Use cases Shadow Launch : (1) migration database (replace MySQL by Postgres) — dual-write to both, read from old, validate new returns same results before cutover ; (2) microservice extraction (split monolith) — shadow new microservice consuming events, validate output match monolith logic before switching reads ; (3) ML model deployment — shadow new model alongside production, compare predictions, A/B impact before promotion ; (4) cache layer addition — dual-read cache + DB, validate hit rate et freshness ; (5) infrastructure migration (AWS region migration) — duplicate traffic to new region, monitor latency/errors before cutover.

Facebook history : popularised "dark launch" approach with chat feature 2008 — backend deployed for months processing user data invisibly, measuring scale needed, before UI release. Modern norm : Facebook, Google, Netflix dark launch features routinely.

Techniques de duplication traffic : (1) Service mesh (Istio mirror traffic to v2 percentage) — shadow with response discarded ; (2) Load balancer dual-routing ; (3) Application-level (dual-call both services, compare, return primary) — use circuit breaker for safety ; (4) Kafka topic copy with two consumer groups ; (5) Diffy (Twitter open source) — diff service for HTTP API ; (6) Spotify Backstage techdocs explain shadow deployment patterns.

Monitoring durant Dark Launch : (1) error rate du shadow code (toujours captured et alerté même si non-userfacing) ; (2) latency comparison shadow vs production ; (3) resource consumption (memory leak detection avant impact users) ; (4) output divergence — automated diff (counting % responses identiques, ML-based similarity scoring) ; (5) downstream impact (database load, dependent services).

Dangers et best practices : (1) attention si shadow service mutates state (DB writes, external API calls) — peut corrompre data ou cause side effects (envoyer email twice) ; (2) double-cost infrastructure pendant shadow window ; (3) avoid eternal shadow — set end date et decision criteria upfront ; (4) communicate clearly à équipe que shadow service running ; (5) ensure shadow isolated du critical path (cannot impact production latency or stability).

Commonly combined avec : (1) Canary deployment (shadow → canary → full rollout) ; (2) Feature flags (hidden launch); (3) Progressive delivery (Flagger, Argo Rollouts). Compétences DOP-C02, AZ-400.