Operations

Zero-Downtime Deployment Prompt

Ship without a maintenance window — a deployment strategy (blue-green or rolling) that keeps the service up, handles in-flight requests, and stays compatible across versions.

Overview

A deploy that needs downtime is a deploy you'll postpone — and postponed deploys get big and risky. This prompt designs a zero-downtime strategy: blue-green or rolling, how traffic shifts, how in-flight requests and connections drain, and the backward-compatibility rules (API, schema, sessions) that let two versions run side by side during the switch.

Why This Works

Choosing the pattern on real constraints beats cargo-culting blue-green
Compatibility rules are what make two-version coexistence safe, not luck
Connection draining is the detail that separates zero-downtime from dropped requests

Best for

Services where downtime is unacceptable or expensive
Frequent deploys that can't each take a window
Stateful services that complicate naive deploys

Not for

Internal tools where a brief window is fine
The data-migration specifics — use the Database Migration Plan Prompt

Use cases

Designing a blue-green or rolling deploy
Eliminating the maintenance window from releases
Handling in-flight requests during a version switch

Customize This Resource

Opens this resource in the related tool with the fields pre-filled. Customize role, tone, and behavior rules — then generate your prompt.

Prompt Template

ROLE
You are designing a zero-downtime deployment strategy for a running service.

INPUT
The service and constraints:
[Architecture, traffic, statefulness, current deploy method]

PRODUCE A STRATEGY
1. PATTERN: blue-green vs rolling vs other — chosen on the service's constraints, with the trade-off.
2. TRAFFIC SHIFT: how requests move from old to new (load balancer, DNS, service mesh) and how fast.
3. IN-FLIGHT WORK: how active requests, connections, and background jobs drain without being dropped.
4. VERSION COMPATIBILITY: the rules that let old and new run simultaneously — backward-compatible APIs, schema (expand/contract), session/cache compatibility.
5. HEALTH GATING: the checks the new version must pass before it takes traffic, and the automatic abort if it doesn't.
6. STATEFUL CONCERNS: anything stateful (sessions, sticky connections, in-memory data) and how it survives the switch.

RULES
- Two versions WILL run at once — every compatibility rule must hold during that window.
- No request in flight may be dropped by the switch.

OUTPUT
The chosen pattern with rationale, the traffic-shift and draining plan, and the version-compatibility rules.

Related Resources

Explore more resources that work well with this one.

Related Tools

Markdown Output Builder

Tip: Save time by exploring related resources and tools that integrate with this workflow.

Explore all resources