🟢Zero Downtime Deployment Strategies

Release changes without interrupting user traffic or breaking in-flight requests.

📌 Key IdeaZero-downtime deployment means users continue to use your system while new versions roll out. Core patterns are rolling, blue-green, and canary deployments, combined with health checks, backward-compatible DB changes, and fast rollback.

📖

Definition

A zero-downtime deployment strategy updates services incrementally while maintaining availability targets. It requires both traffic strategy and data/schema compatibility strategy.

✨

Why It Matters

Avoids visible outages during releases and improves user trust.
Reduces blast radius when a bad release occurs.
Enables frequent deployments with lower operational risk.

💻

Code Variations

1️⃣ Backward-compatible DB migration sequencetext

Release 1:
- Add nullable column/new table
- App writes both old + new shape

Release 2:
- App reads new shape only

Release 3:
- Remove old column/path

Never deploy code requiring a schema that is not yet present.

2️⃣ Example canary progression policyyaml

steps:
  - traffic: 1%
    hold: 10m
    abort_if:
      error_rate_gt: 1%
      p99_latency_gt: 400ms
  - traffic: 10%
    hold: 20m
  - traffic: 50%
    hold: 30m
  - traffic: 100%

Define objective rollback thresholds before rollout starts.

3️⃣ Zero-downtime release checklisttext

- Readiness + liveness checks configured
- Graceful shutdown drains in-flight requests
- Timeouts/retries tuned for dependency transitions
- Schema migration backward compatible
- Rollback plan tested

📊

Deployment strategy trade-offs

Aspect	Strength	Main risk
Rolling	Simple and resource-efficient	Mixed-version compatibility issues
Blue-Green	Fast switch + easy rollback	Higher infra cost (double environments)
Canary	Limits impact via gradual traffic shift	Needs strong observability + control plane
Feature Flags	Decouple deploy from release	Flag sprawl and stale toggles

🔀

Common Confusions Cleared Up

Deploy vs release

Deploy is shipping code artifact. Release is exposing behavior to users. Feature flags let you deploy safely and release gradually.

Availability can drop without hard downtime

Even if service remains “up,” latency/error spikes during rollout violate SLOs. Zero-downtime strategy must protect both uptime and performance.

🧪

Variations / Implementations

1) Rolling deployment

Replace instances in batches (e.g., 10-20%) while others serve traffic. Requires readiness checks and cross-version API compatibility.

2) Blue-Green deployment

Run old and new environments in parallel. Validate new (“green”), then switch traffic atomically. Roll back by switching back.

3) Canary deployment

Route small traffic percentage to new version (1% -> 5% -> 25% -> 100%) based on error/latency guardrails.

⚠️

Common Mistakes / Anti-Patterns

Schema-breaking changes in same release as app change.
No readiness probe (traffic sent before app warm-up).
No graceful shutdown causing dropped in-flight requests.
Canary without observability/automatic rollback triggers.
Rollback that forgets data compatibility path.

🎤

Interview Q&A

🧾

Quick Cheat Sheet

Golden ruleBackward compatibility first (API + schema).

Safest rolloutCanary with measurable abort criteria.

Fastest rollbackBlue-green traffic switchback.

Data migrationExpand -> migrate -> contract.

🔗