Rolling Deployment

The Mechanics

 replace old instances with new ones in small batches:

 [v1 v1 v1 v1]  →  [v2 v1 v1 v1]  →  [v2 v2 v1 v1]  →  [v2²]

 per batch (kubernetes default behavior):
 1. new pod starts, passes readiness probes
 2. endpoints add it; traffic flows proportionally  
 3. old pod: stop NEW traffic; grace period for in-flight;
    terminate
 4. proceed until fleet converted

 k8s knobs:
   maxSurge: 1      ← extra pod above desired count during roll
   maxUnavailable: 0← never below capacity (zero-downtime posture)

The Capacity Math

 rolling assumes MIXED VERSIONS coexist safely:

 □ N+1 protocol compatibility: v1 clients ↔ v2 servers AND
   vice versa during the window (backward-compatible-migrations
   lessons apply to APIs too!)
 □ shared resources must tolerate both versions' patterns:
   schema (expand-first!), cache formats, queue payloads
 □ CAPACITY during surge: maxSurge pods need room —
   cluster headroom planning includes deployment surges,
   or rolls get stuck Pending at peak

 batch-size tradeoff:
   big batches: faster rollout, bigger simultaneous-blast-risk
   small batches (25%→10%→1 pod): slower, safer, gentler
   on shared dependencies (cache-warming storms scale with batch)

Failure Modes and Their Catches

Failure	Signature	Catch
bad v2 rolls fully before symptoms	incident AFTER 100%	readiness gates + canary-before-roll
slow-start regression	p99 climbs mid-roll	automated metric gates pausing rollout
connection drain ignored	error spikes on terminate	preStop hooks + graceful shutdown
probe lies (ready too early)	errors from fresh pods	real readiness checks (deps warmed!)
config/schema mismatch mid-roll	version-pair errors	expand-contract discipline

 the readiness-probe lie deserves emphasis:
 "container started" ≠ "able to serve". warm caches, load
 configs, verify dependency reachability BEFORE reporting
 ready — otherwise every roll injects a brief error burst.

When Rolling Is the Right Default

 ✓ stateless services (the overwhelming majority)
 ✓ mixed-version tolerance maintained by discipline
 ✓ capacity headroom exists for surges

 consider alternatives when:
 ✗ need EXACTLY one version live at once (some licensing/
   consistency postures) → blue-green
 ✗ want user-cohort-based exposure control → canary+mesh
 ✗ stateful stores with complex promotion → dedicated playbooks

 even WITH fancier options, rolling remains the substrate —
 canary IS a rolling deployment with gates between steps.
 learn this one deeply first.

Interview Framing

“Deploy a stateless API with zero downtime” scored shape: rolling mechanics with maxSurge/maxUnavailable semantics, mixed-version compatibility requirement named explicitly, readiness-vs-liveness distinction applied, drain/graceful-shutdown detail included, failure-mode table condensed. This is THE baseline deployment question — fluency here is assumed before fancier strategies are even discussed.