TL;DR: Canary, with automated rollback on an error-rate and latency signal, because a payments API cannot afford a full-blast bad release and cannot afford to double its infrastructure permanently either. Blue-green is another option when spare capacity and fast routing cutover justify a second fleet; state compatibility still controls recovery.
How to approach it
Make the call in your first sentence, then justify it with the two constraints that decide it: how much money the blast radius costs, and how fast you need to be back. Then say what would change your mind. A menu of three options with pros and cons is the answer that fails this round.
A strong answer
Rolling replaces pods in batches. maxSurge can require extra capacity; avoiding surge usually trades away some availability through maxUnavailable. Rollback is another rollout whose duration depends on readiness, image availability and capacity. Without a separate routing layer, replica counts approximate each version’s traffic share.
Blue-green stands up a complete second environment and flips the router. Routing can flip back quickly if the old fleet is still healthy; draining connections and checking state compatibility can take longer. The cost is roughly double the infrastructure for the duration, plus the hard part nobody mentions: the database. Blue and green share it, so the schema must be compatible with both versions simultaneously, which means expand and contract migrations rather than a single ALTER.
Canary sends a small slice of real traffic to the new version, watches signals, and promotes or aborts. Typical progression is 1 percent, 5 percent, 25 percent, 100 percent with a soak at each step. Canary capacity grows with traffic and per-pod load. Keeping the stable fleet fully provisioned can approach a second fleet’s cost late in rollout; Argo Rollouts documents the scaling choices.
For a payments API I take canary. A 1 percent traffic slice bounds direct exposure, but a canary can still overload a shared database or corrupt shared state, and the promotion gate can be automated on a metric rather than a human watching a dashboard. The gate matters: Argo Rollouts or Flagger comparing error rate and p99 against the stable version, aborting automatically. Manual approval can supplement automated analysis, especially for risks the available metrics cannot detect.
| Extra capacity | Rollback time | Blast radius during rollout | Best for | |
|---|---|---|---|---|
| Rolling | Configured surge | Another rollout | Growing, potentially all users | Internal and low-risk services |
| Blue-green | Roughly a second fleet | Routing switch plus drain/state checks | All users at the flip | Big-bang releases needing instant undo |
| Canary | Scales with traffic and stable-fleet policy | Abort routing, then verify recovery | Traffic slice; shared dependencies can widen it | User-facing services with real metrics |
What changes my mind: if the release involves an irreversible data migration, canary is dangerous because two versions write concurrently, and I would sequence an expand-and-contract migration first and deploy the code separately. If the service has no meaningful traffic, canary has no signal, so blue-green with a synthetic check is more honest.
The failure mode to name unprompted: a canary that passes for nine minutes and fails at forty. Short soaks only catch immediate errors. Slow leaks, connection pool exhaustion and cache-warming effects need a soak long enough to reach steady state, which is why a fixed five-minute canary on every service is a policy rather than a safeguard.
What interviewers probe next
"Your canary error rate spikes at 5 percent traffic. What happens?" The analysis run fails its threshold, the rollout aborts, and traffic returns to stable automatically. Then I check whether the metric was scoped to the canary pods only, because a fleet-wide metric dilutes the signal and is the most common reason a canary passes when it should not.
"How do you canary a database change?" You do not. You separate schema from code with expand and contract: add the new column, deploy code that writes both and reads old, backfill, switch reads, then drop. Keep the old representation until rollback no longer needs it. Dropping data is destructive; restoring it requires a separate recovery plan.
"What signal do you gate on?" Error rate and p99 latency of the canary compared against stable over the same window, plus a business metric if one exists. Use both an absolute SLO threshold and comparison with stable. Both versions can degrade together when a shared dependency fails.
Common mistakes
Listing all three with pros and cons and no recommendation. The question asked you to pick.
Forgetting the database in blue-green. It is the reason blue-green fails in practice, and leaving it out signals you have read about it rather than run it.
Treating rollback as a plan rather than a rehearsal. If you have never executed the rollback path, you have a document, not a capability.