Dark Launching

What is dark launching?

Dark launching deploys a feature into production but keeps it invisible to users — the code runs, often against real production traffic, but its results are hidden, discarded, or shown only to internal accounts. The point is to test a feature’s performance and correctness under real load before exposing it. Classic example: you build a new recommendation engine, deploy it, and silently run every real request through it (comparing its output to the old system, measuring its latency and error rate) without ever showing users its results — until you’re confident, then you flip it on.

How it relates to feature flags and other rollout strategies

Dark launching is usually implemented with feature flags — the deployed-but-dark code is gated behind a flag that’s off for users but on for measurement. It embodies the principle of decoupling deployment from release: the code ships to production (deployment) long before users experience it (release), which is the foundation of modern continuous delivery. It complements rather than replaces the traffic-shifting strategies: canary release exposes a real feature to a small group; dark launching exposes a hidden feature to a large group (potentially all traffic) to load-test it silently. You often sequence them — dark launch to validate performance and correctness invisibly, then canary to expose gradually to real users. The related term “shadow traffic” or “traffic mirroring” describes duplicating live requests to the new system in parallel, which is dark launching’s most rigorous form.

Why teams use it — and where it gets tricky

The value is de-risking: you learn how a feature behaves against production-scale, production-shaped traffic — the load and data patterns you can never fully reproduce in staging — before a single user depends on it. This is especially valuable for performance-sensitive changes (a new search backend, a rewritten pricing engine) where the failure mode is “it works but it’s too slow” or “it works but returns subtly wrong answers under real data.” The tricky parts are side effects: if the dark feature writes to databases, sends notifications, or calls paid external APIs, running it silently on all traffic can corrupt data, spam users, or run up costs — so dark launches must carefully suppress or sandbox any real-world effects, keeping only the measurement.

What people get wrong

• Unsuppressed side effects — a dark feature that writes data or calls paid APIs on live traffic causes real damage while “hidden.”
• Confusing it with canary: dark launching hides results from many users to load-test; canary shows a real feature to few users.
• Skipping cleanup — the flags and shadow paths accumulate as tech debt if not removed after the feature goes live.

Primary source: Martin Fowler: Feature Toggles (dark launch)