Compare deployment strategies — rolling, blue/green, canary, and feature flags — and explain how you'd choose per service.

The decision inputs: (1) cost of a bad release — a tier-3 internal tool takes rolling; payments takes canary with automated verification; (2) rollback speed needed — blue/green's instant switch beats rolling's re-deploy; flags roll back in milliseconds without any deploy; (3) observability maturity — canary without trustworthy per-version metrics is theater; you need version-labeled error/latency signals and ideally automated analysis before canary buys you anything; (4) state — schema changes break naive blue/green (both environments share the database mid-transition; you need expand/contract migrations regardless of strategy); sticky sessions complicate canary traffic splitting; (5) traffic volume — a 1% canary on 100 rps is 1 request/second: statistical confidence needs minutes-to-hours, so low-traffic services often do better with blue/green + synthetic checks. Real systems compose them: deploy dark behind a flag (deploy≠release), canary the infrastructure rollout, then release progressively via flag targeting — with the flag as the instant kill switch. The named trap: feature-flag debt — stale flags multiply code paths and test matrices, so flags need owners and expiry like TODOs with teeth.