Use backward-compatible, staged releases. Deploy additive database changes first, then application code that can handle old and new representations, backfill in bounded batches, switch reads, and remove obsolete structures in a later release. Run multiple healthy instances behind a load balancer with readiness checks and graceful shutdown. Use rolling, blue-green, or canary deployment; stop and roll back automatically on error rate, latency, or business-metric regression. Keep configuration and secrets external, make startup migrations controlled and observable, and ensure background jobs have single-owner/idempotency protection. A rollback plan must cover schema and message compatibility, not only the application binary.
Backbencher Developer · · 0 likes