“Zero downtime” is the promise every DevOps tool makes. It’s on every landing page, in every conference talk, embedded in every CI/CD pipeline tutorial. But after deploying to production 2,847 times last year, we’ve learned that “zero” is more of a marketing term than a technical reality.

This isn’t a takedown piece. These strategies work. But they work differently than the docs suggest, and the gap between theory and practice cost us more debugging hours than we’d like to admit.

The Experiment

We run a B2B SaaS platform with approximately 12,000 concurrent users during peak hours. Our stack:

Over six months, we systematically tested five deployment strategies, measuring three things:

• Error Rate During Deploy — HTTP 5xx responses during the deployment window
• Latency Impact — P99 latency change during deployment
• True Deployment Time — From git push to fully stable (not just “rollout complete”)

Here’s what we found.

Strategy 1: Rolling Updates

The Kubernetes default. Old pods are gradually replaced with new ones. Simple, built-in, and the strategy most teams use without thinking about it.

spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1

The 0.3% error rate doesn’t sound bad until you realize that’s roughly 10 errors per second during the 4-minute window. For our users, that’s failed form submissions, lost data, and support tickets.

The fix: We added a startup delay and pre-warming script that makes synthetic requests before the pod accepts real traffic.

#!/bin/bash
# Hit critical endpoints to warm up V8
for i in {1..100}; do
  curl -s http://localhost:3000/api/health > /dev/null
  curl -s http://localhost:3000/api/users/warm > /dev/null
  curl -s http://localhost:3000/api/products/warm > /dev/null
done
echo "Prewarm complete"

Strategy 2: Blue-Green Deployment

Run two identical environments. Deploy to the inactive one, test it, then switch traffic. The classic “instant rollback” strategy.

  ┌─────────────┐
  │   Users     │
  └──────┬──────┘
         │
         ▼
  ┌─────────────┐
  │ Load Balancer│
  └──────┬──────┘
         │
    ┌────┴────┐
    ▼         ▼
┌───────┐ ┌───────┐
│ BLUE  │ │ GREEN │
│ v2.1  │ │ v2.2  │
│(live) │ │(idle) │
└───────┘ └───────┘

The asterisk on “Yes” is important. Blue-green works beautifully for stateless services. But we hit problems:

• 1 Database migrations — If v2.2 needs a schema change, you can’t just switch back to v2.1
• 2 WebSocket connections — Existing connections don’t magically move to the new environment
• 3 Cost — Running 2x infrastructure adds up ($4,200/month in our case)

Strategy 3: Canary Releases

Route a small percentage of traffic to the new version. Monitor. Gradually increase. This is the strategy everyone says they want to implement “someday.”

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-canary
            port: 
              number: 80

Canary gave us the best error rates, but the deployment time killed our velocity. With 8-12 deploys per day, spending 30+ minutes per deploy wasn’t sustainable.

We also learned that canary requires serious observability investment:

Without automation, someone has to babysit every deploy. We built the automation eventually, but it took two engineers three weeks.

Strategy 4: Feature Flags + Rolling

Decouple deployment from release. Ship the code with features disabled, then enable them gradually via flags. This changed everything for us.

const LaunchDarkly = require('launchdarkly-node-server-sdk');

async function getSearchResults(query, userId) {
  const useNewAlgorithm = await ldClient.variation(
    'new-search-algorithm',
    { key: userId },
    false  // default: use old algorithm
  );
  
  if (useNewAlgorithm) {
    return newSearchService.search(query);
  }
  return legacySearchService.search(query);
}

The key insight: deployments become boring. You’re just shipping code that doesn’t do anything new yet. The risky part—enabling the feature—happens separately, and you control exactly when and for whom.

Strategy 5: Shadow/Dark Launching

Mirror production traffic to the new version without returning its responses to users. Compare results. Only switch when confident. This is the nuclear option.

        ┌─────────────┐
        │   Request   │
        └──────┬──────┘
               │
               ▼
        ┌─────────────┐
        │   Router    │
        └──────┬──────┘
               │
      ┌────────┼────────┐
      │        │        │
      ▼        │        ▼
  ┌───────┐    │    ┌───────┐
  │ v2.1  │    │    │ v2.2  │
  │ LIVE  │    │    │SHADOW │
  └───┬───┘    │    └───┬───┘
      │        │        │
      ▼        │        ▼
  Response ◄───┘    Logged &
  to User           Compared

Technically perfect. Practically… we use this maybe twice a year for major rewrites. The infrastructure overhead and analysis time make it impractical for daily deploys.

What We Actually Use

After six months of testing, here’s our current deployment matrix:

The honest answer is: there’s no single “best” strategy. The right choice depends on your service, your risk tolerance, and how fast you need to ship.

Key Takeaways