Design Rolling Update Strategy

What We Are Building

A rolling update strategy replaces running application instances gradually — one batch or one pod at a time — while keeping enough healthy capacity to serve traffic. Unlike big-bang deploys, the service never drops to zero replicas. Kubernetes Deployments, AWS Auto Scaling Groups, Google Managed Instance Groups, and Azure VM Scale Sets all implement variants of this pattern.

Why interviewers ask this

Tests whether you understand capacity math during deploys (maxSurge, maxUnavailable).

Probes health gates: readiness vs liveness, connection draining, warm-up time.

Separates candidates who say "just deploy" from those who design partial rollback and observability on new revision cohorts.

Core actors

Release engineer: triggers rollout, watches SLIs, pauses or rolls back.

Rollout controller: schedules create/terminate waves, respects PDBs.

Load balancer / service mesh: registers healthy targets, drains old connections.

SRE: tunes bake time, error-rate thresholds, audit compliance.

Real-world anchors

Google production deploys often use rolling updates with automated health checks; AWS ASG RollingUpdate policy; Kubernetes default RollingUpdate with surge=25%, unavailable=25%.

javaOne Dark Pro

1 public final class RollingUpdateWavePlanner {
2   private final int maxSurge;
3   private final int maxUnavailable;
4  
5   public WavePlan plan(int desired, int readyOld, int readyNew) {
6     int surgeBudget = (int) Math.ceil(desired * (maxSurge / 100.0));
7     int unavailableBudget = (int) Math.floor(desired * (maxUnavailable / 100.0));
8     int canCreate = Math.max(0, surgeBudget - (readyNew - desired));
9     int canTerminate = Math.max(0, readyOld - (desired - unavailableBudget));
10     return new WavePlan(canCreate, canTerminate);
11   }
12 }

pythonOne Dark Pro

1 def should_advance_wave(
2     new_error_rate: float,
3     old_error_rate: float,
4     min_bake_seconds: int,
5     elapsed: int,
6 ) -> str:
7     """Return promote, hold, or rollback for rolling update wave."""
8     if new_error_rate > old_error_rate + 0.002:
9         return "rollback"
10     if elapsed < min_bake_seconds:
11         return "hold"
12     return "promote"

typescriptOne Dark Pro

1 export interface RolloutPolicy {
2   maxSurgePercent: number;
3   maxUnavailablePercent: number;
4   minReadySeconds: number;
5 }
6  
7 export function nextBatchSize(
8   desired: number,
9   policy: RolloutPolicy,
10   readyNew: number,
11 ): number {
12   const surge = Math.ceil((desired * policy.maxSurgePercent) / 100);
13   const headroom = Math.max(0, surge - (readyNew - desired));
14   return Math.min(headroom, Math.max(1, Math.floor(desired * 0.25)));
15 }

How to open this one

The framing that signals depth on rolling updates is the surge/unavailable math: you replace instances in waves bounded by maxSurge and maxUnavailable, guarded by a PodDisruptionBudget, so capacity never drops below what live traffic needs. Lead with readiness gating — a new pod takes traffic only after its readiness probe passes — and the failure story that matters: a bad version rolls partway, fails readiness, and the rollout halts itself before the whole fleet is replaced. That shows you understand rolling updates self-limit their own blast radius.

Key Highlights

•maxSurge adds capacity; maxUnavailable caps downtime during waves.
•Readiness gates traffic; liveness restarts — do not conflate them.
•Drain connections before terminate to avoid user-visible errors.
•Compare error rate by revision before advancing the next wave.

Problem Statement: Rolling Update Strategy