Summary
Deploying code and releasing a feature are two distinct events. Blue-green and canary strategies control which server version handles traffic. Feature flags go further: a single production build can gate features per user, cohort, or percentage — enabling instant kill-switches without a redeploy.
Jump to the interview angleDeploy ≠ release
Deployment puts new code on servers. Release exposes it to users. Mixing the two forces high-stakes big-bang rollouts. Separating them — via traffic routing or feature flags — means you can ship code continuously and release when ready.
Blue-green vs canary
| Dimension | Blue-green | Canary | |
|---|---|---|---|
| Traffic split | 100% flips from old to new at once | Small % (e.g. 5%) routes to new; grows over time | |
| Rollback speed | Instant — flip DNS or LB weight back to blue | Redirect canary slice back; no full cutover needed | |
| Infrastructure cost | Doubles compute — two full environments live | Lower — canary slice is a fraction of fleet | |
| Risk exposure | All users hit new build simultaneously after cutover | Only canary cohort exposed; blast radius is small | |
| Best fit | Short-lived releases, DB migrations, compliance freezes | Gradual feature rollout with real-traffic validation |
Feature flags beyond traffic routing
- Flags gate features in code, not at the load balancer — one binary serves all users.
- Percentage rollout: increment from 1% to 100% while monitoring error rates.
- Kill switch: set flag to off for everyone in seconds, no redeploy required.
- Flag state should be evaluated server-side or at the edge to avoid UI flicker on load.
- Flag debt accrues fast — delete flags within one sprint of full rollout.
Server-side flag evaluation in Next.js
Evaluating flags in a Server Component or edge middleware prevents the client seeing the wrong variant on first paint.
// app/checkout/page.tsx (Next.js 15 App Router)
import { headers } from "next/headers";
import { getFlag } from "@/lib/flags"; // wraps your flag provider SDK
export default async function CheckoutPage() {
// Runs on the server — no client round-trip, no flicker
const newFlow = await getFlag("checkout-v2", {
userId: headers().get("x-user-id") ?? "anon",
});
return newFlow ? <CheckoutV2 /> : <CheckoutV1 />;
}getFlag calls your provider (e.g. LaunchDarkly, Statsig) once per request. The decision is baked into the HTML stream — the client never sees a layout shift.
Interview angle
Interviewers test whether you know deploy and release are separate concerns. Name blue-green vs canary trade-offs, explain flag evaluation at the server/edge to prevent flicker, and call out flag debt as a real maintenance cost.
Soundbite: "Deploy the code dark, release with a flag — rollback is a config change, not a redeploy."
Key terms
- Blue-green deployment
- Two identical environments; traffic flips 100% from old (blue) to new (green) atomically.
- Canary deployment
- New build receives a small traffic slice (e.g. 5%) before gradual promotion to 100%.
- Feature flag
- A runtime boolean (or multivariate value) that gates code paths without a redeploy.
- Kill switch
- A feature flag set to off for all users instantly; stops an incident without rollback.
- Flag debt
- Stale flags that remain in code after full rollout, adding dead branches and review cost.