Zero downtime is compatibility over an overlap window
Zero-downtime deployment means old and new instances can serve traffic during rollout without disagreeing on contracts or data. The central technique is compatibility: additive changes first, code that tolerates both shapes, data migration while both versions run, and destructive cleanup only after old consumers are gone.
Application and schema versions must coexist
- Expand schema with nullable/new fields or tables before requiring them.
- Deploy code that can read old/new shape and writes the transition-safe form.
- Backfill data separately with observable progress and throttling.
- Shift traffic only when new instances pass readiness.
- Contract/remove old columns, routes, or event fields in a later release.
Expand, deploy, migrate, contract
Schema expansion precedes code rollout; data is migrated while versions coexist; destructive contraction waits until no old reader remains.
Expand–migrate–contract rollout
Schema expansion precedes code rollout; data is migrated while versions coexist; destructive contraction waits until no old reader remains.
Renaming a database field without an outage
Changes that cannot be made atomically
Zero-downtime checklist
- Identify old/new compatibility window.
- Use additive database and API changes first.
- Make rollout and rollback both schema-compatible.
- Observe backfill and readiness before traffic shift.
- Remove old contract only after consumer inventory is clear.
