Dark Launch

A dark launch releases code or a backend path into production in a hidden state. Real requests exercise it, often through traffic mirroring or a feature flag, but its results are not shown to users.

Why it matters

Staging environments rarely match production load or data. A dark launch lets you observe latency, error rates and resource use under real conditions before anyone depends on the feature. If something misbehaves, you turn it off, and users never saw it. It is related to canary releases, but the difference matters: a canary exposes a small share of users to the new version, while a dark launch exposes none.

Example

A new search service runs alongside the old one. The application calls both, returns the old result, and logs the comparison:

result_old = search_v1(query)
if flag("search_v2_shadow"):
    result_new = search_v2(query)   # not returned
    log_diff(result_old, result_new)
return result_old

After a week of matching results and acceptable latency, the team ramps the flag to real users.

Common mistakes

• Shadow traffic that triggers side effects such as emails or payments twice.
• Doubling load on a shared database without capacity headroom.
• Never cleaning up the flag and the dead code path afterward.

Related

• Feature flag
• Canary release
• Blue-green deployment
• Rollback

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.