Master the terminology behind safely validating new services with mirrored production traffic.
0 / 5 completed
1 / 5
At standup, a dev proposes sending a copy of real production requests to a new service version without returning its responses to users. What is this technique called?
Shadow traffic (traffic mirroring) duplicates real production requests to a new version so its behavior can be observed under real load, while the actual user-facing response still comes from the current stable version. This lets a team validate a new implementation with zero user-facing risk. It differs from a canary, which does expose some real users to the new version's actual responses.
2 / 5
During a design review, the team wants to compare the new service's output against the current version's output for the same requests. What is this comparison process called?
Response diffing compares the shadowed service's output to the production version's actual response for identical requests, surfacing behavioral discrepancies before the new version ever serves real users. This turns shadow traffic from passive observation into an active correctness check. It is a common companion technique to traffic mirroring.
3 / 5
In a code review, a dev flags that the shadow-traffic target performs a write operation identical to production, risking duplicate side effects. What should be addressed first?
Because shadow traffic mirrors real requests, a shadowed service that performs real side effects, like writes, emails, or payments, can cause duplicate or unintended actions unless those effects are stubbed or isolated for the shadow path. This is a critical safety consideration before mirroring write-heavy traffic. Read-only endpoints are generally much safer to shadow than mutating ones.
4 / 5
An incident report shows shadow traffic overloaded the new service and skewed its latency metrics. What should the team check?
If the shadowed target isn't provisioned to handle the full mirrored traffic volume, its performance metrics under shadow load won't accurately represent how it would perform in real production conditions. Matching capacity between the shadow and eventual production deployment keeps the comparison meaningful. Otherwise the exercise can produce misleading conclusions about readiness.
5 / 5
During a PR review, a teammate asks how shadow traffic differs from a canary release. What is the key distinction?
Shadow traffic observes a new version's behavior on copied requests while real users still get the current version's response, whereas a canary release actually serves a small percentage of real users the new version's real response. Shadowing is purely observational with zero user-facing risk; canarying accepts limited real risk to validate under authentic conditions. Teams often use shadowing first, then canary, as sequential validation steps.